7

master支店があれば。

次に、workブランチをチェックアウトして素晴らしい変更を加え、いくつかコミットします。

次に、何かを修正する必要があるため、 に戻ってmasterというブランチをチェックアウトし、fix必要なことを修正して、 にマージしmasterます。

私の質問は、次にマージmasterしworkて続行する必要があるか、それとも以前のwork場所を続行して、完了したらマージする必要があるかということです。

作業しているすべてのブランチに戻って、各ブランチを更新 (変更をマージ) しなければならないことに気づきました。

できるだけ早くマージするのが最善だと感じていますが、作業しているすべてのブランチを継続的に更新する必要があることに気付きます。これは不要ですか？

4

3 に答える 3

9

Nive による常に素晴らしい Git Branching Model を参照してください。

ここに画像の説明を入力

ほら、 （別名）ブランチにfix（ではなくmaster）マージする必要があります。workdevelop

どのくらいの頻度で にマージする必要がありますmasterか? もちろん、すべての安定版リリース。

他に疑問はありますか？写真を見てください。：P

ソース: http://nvie.com/posts/a-successful-git-branching-model/

于 2012-10-08T10:18:30.773 に答える
3

あなたは実際にあなたがしていることである「バックマージ」をしたくありません。何が機能するかを確認したいものをマージする統合またはリリース候補のブランチが必要です。Google の「Branch per Feature」で、作業を整理し、同期し、柔軟に保つ方法を確認してください。

于 2012-09-27T23:35:46.233 に答える
1

マスターが前進したとき、次のことを行います。

git fetch               # get the latest master
git checkout my_branch  # work in my_branch
git rebase master       # replay my work on top of newer master

変更されたマスター (たとえば、a が適用されたとき) を最新の状態に保ちfix、次にブランチをマージしたとき

git checkout master     # Do the work in master
git merge my_branch     # Bring in my branch

変更のために多くの更新を行う必要がないように、ブランチをかなり迅速にマージすることを目指しています。

私たちは 1 日に 2 つまたは 3 つのブランチでのみ作業を行っており、ブランチが開発者間で共有されている場合は、次のように最新の状態に保ちます。

get fetch                         # Gets the latest version of branches including my_branch
git checkout my_branch            # Do the work in the my_branch
git reset --hard origin/my_branch # Reset to the latest version fetch in.
于 2012-09-27T23:59:30.967 に答える