結論

いつ切ってもいい。develop が落ち着くのを待つ必要はない。

「自分が開発している間に develop が更新されると、PR を出したときにその更新分まで差分として表示されて、自分のブランチの変更だと勘違いされてしまうのでは？」という不安から、ある程度 develop が固まってから切ったほうがいいのでは、と考えがちです。でも、その不安は杞憂です。

本質：PR の差分には「自分の変更だけ」が出る

待たなくていい本質的な理由はこれです。PR の差分は、develop の更新分まで含めて表示するわけではありません。

差分の実体は、最新の develop と最新の feature を比較したものです。ただし単純な引き算ではなく、枝分かれした地点（自分が feature を切った時点）を基準点にして、「develop 側だけで増えた変更」と「feature 側だけで増えた変更」を切り分けます。そして差分として見せるのは後者だけ。結果として、自分が feature で加えた変更だけが表示され、develop 側で他人が足した変更は出てきません。

つまり「枝分かれ地点から自分が加えた分だけ」というのは結果的にそう見えるという話で、比較しているのはあくまで最新の develop と最新の feature です。枝分かれ地点は、比較対象そのものではなく、どちらの変更かを仕分けるための物差しとして裏で使われています。

仕組み

具体例で見ます。app.py という1ファイルを題材にします。

出発点（feature を切った時点の develop）

def main():
    print("Hello")

この時点で feature を切り、開発を始めます。

その後、それぞれが別の変更を加える

他人が develop に setup() を追加（あなたの知らないところで）

def setup():            # ← 他人が追加
    print("setup")

def main():
    print("Hello")

あなたは feature に login() を追加

def main():
    print("Hello")

def login():            # ← 自分が追加
    print("login")

PR の差分は「最新の develop と最新の feature」を比べる

ここで PR を出します。差分が比べるのは、最新の develop と最新の feature です。ただし「枝分かれ地点」を基準点に加えた次の3つを照らし合わせて、変更を仕分けます。

状態	`setup()`	`login()`
枝分かれ地点（切った時の develop）	無い	無い
develop の最新	ある	無い
feature の最新	無い	ある

この表から、こう判定されます。

setup() … 枝分かれ地点には無く、develop 側だけで増えた → 他人の変更 → 差分に出さない
login() … 枝分かれ地点には無く、feature 側だけで増えた → 自分の変更 → 差分に出す

結果、PR の差分はこうなる

  def main():
      print("Hello")
+
+ def login():
+     print("login")

他人が足した setup() はどこにも出てきません。出るのは自分が足した login() の分だけ。develop が更新されていても、レビュアーが見る差分はあなたの作業に絞られます。

一行でまとめると、

PR の差分の実体は「最新の develop ⇔ 最新の feature」の比較。ただし枝分かれ地点を基準に切り分けるので、結果として出るのは自分が feature で加えた変更だけ（develop 側の他人の変更は含めない）。

注意点

1つだけ。PR の比較対象（base ブランチ）が古い develop を指していると、develop の更新分まで差分に出てしまうことがあります。通常 base は自動で最新の develop を指すので普段は気にしなくて大丈夫ですが、「他人の変更が差分に出てしまった」ときはここを疑ってください。

まとめ

feature を切り出す時点は、develop の状態を気にせず「いつでもいい」。PR の差分は自分が加えた変更だけを表示するので、develop が更新されても自分のブランチの変更と勘違いされることはない、というのが答えです。