1

Git を使用して Django プロジェクトに取り組んでいる 3 人がいます。

私は他の 2 人よりも経験が豊富なので、すべての変更は「マスター」に入る前に私が行います。

私たちは皆 Windows を実行しており、ディスクベースの共有が機能する場所ではないため、Linux ボックスの個々のアカウントに個別の「オリジン」リポジトリがあります。これらは、変更を互いに共有する方法として、またリポジトリの「オフサイト」バックアップとして機能します。

他の 2 人のうちの 1 人がブランチを作成し、それを BugA と呼び、修正を行います。次に、彼らはそれを自分の作業マシンから私たち全員がアクセスできる Linux マシンにプッシュして、変更を確認し、それらを私のアカウントの「マスター」にマージできるようにします (これは、本番環境に移行するコードのコピーと見なされます)。

BugA を終了すると、新しいブランチで BugB を開始します。彼らの作業をレビューしていると、いくつかの問題 (余分なコード、コメントの欠落など) が見つかりました。そのため、コードに変更を加えてテストし、master にコミットします。

その後、彼らは BugB の修正を私に送ってくれました。これらの競合は、コミットで変更したコードの行にあります。

彼らが私と合併しようとするとき、彼らは彼らの側でも衝突を報告します。

これを書いているうちに、何が間違っているのか理解し始めていると思います。私は彼らのコードをマスターにマージし、編集とコミットを行っています。私は本当に私のレポで彼らのブランチに変更を加え、それらをマージするためにそれを押し戻し、それからそれらを私のマスターにマージする必要があります。

よくわからないのは、それについて何をすべきかということです。彼らが私のレポからのブランチとマージしたら、マスターとマージする必要がありますか? 1つではなく2つのマージ？

Linux ボックスに外部ホストのレポがあるため、2 回のプッシュ、2 回のマージなどを意味します。

それは本当にそれがどのように機能するべきですか？

4

2 に答える 2

2

私があなたの質問を理解しているように、あなたはすべてが起こっている3つのリモートリポジトリ（「オリジン」）を持っています：

  • あなたのリポジトリ（本番コードを含む）repo_mark
  • user1のリポジトリrepo_user1
  • user2のリポジトリrepo_user2

そして、シナリオは次のとおりです。

  • user1はバグ修正ブランチ（BugA）を作成し、いくつかの修正を行います
  • repo_user1次に、彼は変更を（彼の起源）にプッシュしますgit push origin BugA:BugA
  • 次に、を実行している変更をフェッチgit fetch repo_user1し、ブランチBugA（実行しなければならなかったいくつかの変更を含む）をmaster（グローバルマスターリポジトリと見なされる）のにマージします。 origin

一貫性を保つために、 3つのリポジトリで作業する必要はありません。1つだけ使用します。ガイドラインは、あなただけがプッシュできるようにrepo_mark/masterし、同僚はそのリポジトリのBugfixブランチにプッシュできるようにすることです。

したがって、ブランチを彼の原点（存在しない）にuser1プッシュするのではなく、にプッシュします。BugArepo_mark/BugA

BugAの変更をに入れたら（これはリポジトリrepo_mark/masterと見なされます）、2人の同僚に、作業コピーを更新するように指示します（つまり、where isを実行します）。git fetch originoriginrepo_mark

git checkout master
git rebase origin/master

masterこれで、3人全員が同じブランチを共有します。そして-あなたはあなたの質問でバックアップについて言及しましたfetch-edをしたすべてのユーザーはあなたのrepo_mark今の完全なバックアップを持っています。

これは、 gitに次のように指示して削除するのに適切なタイミングですBugA。repo_mark

git push origin :BugA

そして彼のローカルブランチuser1を削除するために。BugA

BugBその間に作業が開始された場合、作業中のユーザーBugBは

git checkout BugB
git rebase master

あなたが彼に更新するように言った後。いくつかの競合が発生する可能性がありますが、発生する必要はありません。

競合が解決された場合、彼は作業を続行しBugB、最終的に作業をにプッシュすることができrepo_mark/BugBます。

編集：gitへの答え-一部のユーザーのマスターブランチをロックしますか？master同僚のためにロックする方法を示します。

編集2：もちろん、同僚がそこで作業をバックアップできるように、他の2つのリポジトリを保持することもできます。push作業をあなたに渡してからに渡す準備ができるまで、これらのリポジトリに保存pushしますrepo_mark。ただし、その場合、彼らは自分のリポジトリを自分のリポジトリと同期させる責任があり、その場合はオフフックにする必要があります。

于 2011-08-30T13:39:04.380 に答える
0

競合が発生していることを確認できる唯一の方法は、「コードに変更を加える」とは、実際にコミットを変更すること、つまり、新しい SHA1 でコミットを作成し、代わりにそれらをチェックインすることを意味する場合です。履歴を「クリーン」に保とうとしている場合 (私の意見では過大評価されています)、これらの競合を回避する方法はありません。ただし、マージの作業を減らすことがより重要な場合は、コミットを変更する代わりに、その上に修正を含む新しいコミットを作成する必要があります。

これがあなたのコミットの変更方法ではない場合、それはあなたのワークフローに私が見逃している何かがあることを意味します。他に何が思いつくか見てみます。

于 2011-08-30T14:05:01.430 に答える