1

2人の開発者が同時に作業しています。1人はマスター（dev1）で、もう1人は別のブランチ（dev2）で作業しています。マスターは「メインライン」として扱われています。Dev1は、次のようにdev2のブランチからの変更を定期的にマージします。

git checkout master
git merge origin/branch1
git push origin master

これにより、デプロイメントのブランチがマスターとマージされますが、dev2は、マージの完了後にマスターから最新の変更を取得することも必要です。これが最善のアプローチだと思います。

git checkout branch1
git rebase master

これは正しいです？

Githubで、作業中のブランチが表示されなくなり、誰も削除していないことに気付きました。リベースまたはマージは、指示がない限りブランチを削除しないと確信しています。それ以外の場合はお知らせください。

基本的に、グラフは次のようになります。

     b1  b2   b3 b4...
    /      \ /     \
   m1   m2  m3  m4  m5...

m3とm5は、dev1がそれぞれb2とb4をマージする場所です。

4

3 に答える 3

2

リベースは、未公開のコミットdev2をリベースしている場合にのみ有効です。

しかし、リベースされたコミットdev2はすでにオリジンにプッシュされており（そして潜在的にはにマージされdev1ていますmaster）、SHA1が変更されているため、これは正しいアプローチではありません。すでにマージされています。branch1dev1

この特定の状況では、とマージするdev2必要があります–それはそれらの問題を回避します。 mastergit merge master

于 2013-01-31T20:58:25.047 に答える
1

Githubは、マージされたブランチを表示しません。
使用する：

git branch --merged

マージされたすべてのブランチを一覧表示するには

あなたが使うことができます

git log --graph

コミットグラフを表示して、各ブランチがマージされた場所を確認するには

于 2013-01-31T19:14:03.793 に答える
1

これをもう少し調べた後、私が最初に質問で尋ねたものを正確にカバーしているように見えるブログ投稿を見つけました：http: //mettadore.com/analysis/a-simple-git-rebase-workflow-explained/。つまり、マージせずに、代わりにブランチをマスターでリベースし、その逆も同様です。主な違いは、ローカルブランチをプッシュしないことです。

このアプローチの主な理由は、マスターにブランチ履歴を保持し、「複数の人がブランチで作業している場合、他の誰かがマスターブランチをプルして、プルしているのと同じようにマージする場合はどうなるか」という問題を防ぐためです。マージのマスターブランチ？」

私はこれを別の可能なオプションとして追加していますが、誰かがブログで説明されていることに問題を見つけたら、私は興味があります。

于 2013-03-26T22:26:00.343 に答える