新しい機能を作成したとしましょうgit flow feature start FEATURENAME
次に、それを公開しましたgit flow feature publish FEATURENAME
今、私の同僚がこの機能について私と共同作業したいと思っているので、彼はそうします
git flow feature pull FEATURENAME
これにより、リモート リポジトリの機能ブランチに基づいて、ローカル リポジトリに新しいブランチが作成されます。ただし、これはリモート機能ブランチを追跡するようにローカル機能ブランチを設定しないため、このブランチを手動で追跡する必要があります。
この余分な手順の背後にある理由は何ですか? feature pullコマンドも追跡するように設定しないのはなぜですか?
git flow feature pullとのワークフローの違いは何ですかgit flow feature track。
それぞれどのような場合に使用しますか?
Brainimusによるこの回答は、コード レビューとディスカッションの部分を容易にする GitHub プル リクエストの側面を使用して、機能ブランチの共同の側面を示しています。
- 機能ブランチを作成します。
git flow feature start module_1- コードは機能ブランチで更新されます
- 変更がコミットされると、GitHub にプッシュされます (または、必要に応じて最後に 1 回)。
develop機能が完了すると、プル リクエストが GitHub で開かれ、機能ブランチが比較されます。module_1- チームはプル リクエストをレビューし、コメントを作成します
- プル リクエストからの変更は機能ブランチに対して行われます。
- すべての変更がフィーチャー ブランチに組み込まれると、フィーチャー ブランチは終了します。
git flow feature finish module_1developブランチが GitHub にプッシュされます (これが発生すると、GitHub はプル リクエストをクローズ/マージ済みとして自動的にマークします) 。
ただし、そのブランチを閉じるという問題が残ります。
これまでに実行した人
git flow feature finish module_1は、ローカル機能ブランチが削除されるという贅沢を享受できますが、ブランチをチェックアウトした他の人は、必要に応じて手動でこれを行う必要があります
git fetch --prune特にGit 1.8.5以降、configでその「プルーニング」ステップを設定できます。サーバー側で削除された場合、単純なgit fetchで機能ブランチが削除されgit flow feature finishます（他の誰かが.
gitflow 機能は、AVH エディションが単にブランチをチェックアウトして追跡するかどうかを追跡します。つまり、ローカル ブランチがローカル トラッキング ブランチになり、上流ブランチ(リモート トラッキング ブランチ) が関連付けられていることを確認します。
つまり、 と を設定しbranch.<name>.remoteますbranch.<name>.merge。
(新しいローカル機能ブランチに対して) を実行するgit flow feature pullが、実際git flow feature trackには を意味する場合、既存のブランチを上流のブランチに追跡させるだけで済みます。
git branch -u origin/feature
一般的：
git flow feature track、_git flow feature pullgit flow feature checkout「 Getting Started – Git-Flow 」で言及されているように：
git flow feature pull
これは、複数の人が 1 つの機能について一緒に作業する場合に行われます。
次のように、リモート機能ブランチでプルを実行する場合は、このコマンドを使用する必要があります。
git flow feature pull [alias] [featureName]
このコマンドを使用すると、チーム メイトによってプッシュされたソース コードが取得され、その変更がローカル ブランチに自動的にマージされます。
競合が発生した場合、これらの競合の解決を行うのは不運または幸運になります。