彼は明示的にベースコミット()を設定しているので、問題ではありませんdevelop
。コマンドが実行された後、myfeature
以前にチェックアウトされたものに関係なく、彼はブランチにいます。
develop
おそらく追跡するローカルブランチorigin/develop
、リモート追跡ブランチです。
いいえ。git checkout -b myfeature
、明示的な開始点がない場合、に新しいブランチが作成されますHEAD
。develop
ブランチの先端にいる場合は、myfeature
に基づいていdevelop
ます。
ではない正確に。myfeature
参照の先端と同じコミットをdevelop
参照します。「コピー」されるものはありません。myfeature
チェックアウト中に変更をコミットすると、myfeature
ヒントが新しいコミットに更新されます。develop
変更されません。
リモートロケーションで変更を確認する場合は、リモートロケーションにプッシュする必要があります。ローカルブランチにマージするだけでは、リモート側には何も起こりません。
git-flowスタイルで機能を「完成」させたい場合は、開発セクションに完成した機能を組み込むことをお勧めします。に切り替えdevelop
、マージしmyfeature
、削除し、更新された機能myfeature
をにプッシュします。develop
origin
[e]その他の回答:
- 開発内から分岐する場合、それは実行するのと同じです。git checkout -b myfeatureは、開発中でないときに開発しますか?
develop
どちらの場合も、新しいブランチはから始まります。(git branch
同じように機能しますが、新しいブランチに切り替わらない点が異なりますgit checkout -b
。)
- そして、myfeatureを終了するには、develop> git pull> git merge myfeature> git push origin(別名origin / development)をチェックアウトしますか?
大まかに言って、git push origin
必ずしも「別名起源/開発」ではありません。デフォルトgit push origin
では、同じ名前の(または追跡するように設定されている)すべてのローカルブランチを元のブランチにプッシュします。(デフォルトはpush.default
config設定で変更できます。)git push origin develop
ローカルの開発ブランチだけをオリジンの開発ブランチにプッシュします。これは必要なものです。
- マージの前にプルしないと、他の人が行った新しいコミットを上書きするリスクがありますよね?
プッシュを強制する場合のみ(真剣に、それを行わないでください)。マージ後にプルを実行できますが、基本的に2回マージすることになります。最初にプルを実行する方がうまくいきますが、そうしないとデータが失われるリスクはありません。
- 開発をmyfeatureにマージする時期はありますか?
もちろん、他の誰かが更新をプッシュしていてorigin/develop
、その変更を組み込みたい場合。基本的に、機能ブランチを最新の状態に保ちたいが、にマージdevelop
するmyfeature
準備ができていない場合は、にマージしdevelop
ます。
- そして、myfeatureはすべてリリースブランチにマージされますか、それとも常に開発に戻る必要がありますか?
git-flowシステムでは、myfeature
は常にに戻る必要がdevelop
あり、リリースブランチは常にから始まりdevelop
ます。develop
統合テスト、リリース候補など、外部に公開する準備ができている変更のブランチであると同時に、プロジェクトの開発の現在の状態を表すブランチであると想定されています。それはすべての新しいものの出発点です。myfeature
あなたはブランチといくつかのランダムリリースブランチであなたの仕事を終わらせたくはありませんが、メインdevelop
ラインではありません。