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