3

私はまだ git から git-flow に移行しようとしています。私は git-flow 内であらゆる種類の git 機能を使用できることを知っていますが、それが自動的に処理するものに最も興味があります。

Alice と Bob という 2 人の開発者がいて、それぞれ機能 A と機能 B に取り組んでいるとします。Alice が完了したら、コミット C に基づいてgit flow feature finish Aローカルdevelopブランチにマージ コミットを作成することができます。ここで、ボブが機能を同時に終了し、同じものを取得した場合、彼のマージ コミットも C に基づいたものになります。アリスがプッシュし、ボブが再びフェッチした場合、彼はマージまたはリベースする必要があり、彼がマージdevelopした場合に備えて、ブランチに非線形の履歴が残ることになります。

これはこれまでのところ正しいですか、それとも git-flow は何らかの方法でこの状況を自動的に処理しますか? 自動メカニズムがある場合、これが機能するためには何を設定する必要がありますか?

最も簡単な解決策は、機能を終了する前に常にフェッチすることでしょうdevelop。ただし、リポジトリの共有方法によっては、これが実際に可能かどうかはわかりません (その時点では利用できない可能性があります)。

編集（問題の説明）：

答えが示唆するように、私の例は明確ではありませんでした。だから最初に私が問題だと思うものの写真：

C は、develop ブランチの最初のコミットです。

Alice は機能ブランチでいくつかの機能作業を作成します。

develop    feature/A
|           |
v           v
C-A1-A2-A3-A4

同時に、ボブは別の機能にも取り組んでいます

C-A1-A2-A3-A4
 \
  B1-B2-B3-B4

これで Alice は機能を終了し、マージ コミットが追加されて開発されます (私はそれが必要です)。

  A1-A2-A3-A4
 /           \
C-  -  -  -   MA

ここで、Bob が機能を終了し、再びマージ コミットが追加されて開発されます (別の場所でもそれが必要です:

  A1-A2-A3-A4
 /           \
C-  -  -  -   MA <- develop for Alice
 \
  \ -  -  -   - MB <-develop for Bob
   \           /
    B1-B2-B3-B4

ただし、Alice または Bob のいずれかが開発をマージして、追加のコミットを作成する必要があります。

  A1-A2-A3-A4
 /           \
C-  -  -  -   MA-MAB <- I don't want this MAB commit
 \               / 
  \ -  -  -   - MB <-develop for Bob
   \           /
    B1-B2-B3-B4

私が代わりに持ちたいのは次のようなものです：

  A1-A2-A3-A4
 /           \
C-  -  -  -   MA-MB
 \               / 
  B1-B2-B3-B4- -

ご覧のとおり、履歴は依然として非線形ですが、develop ブランチのメイン ラインには機能からのマージ コミットのみが含まれます (他の場合のように追加のマージ コミットは含まれません)。

これについて私が気に入っているのは、履歴の変更を簡単に追跡して、それらが以前の機能ブランチに属しているかどうか、または開発中のマージであったかどうかを確認できることです。このすべての情報は、DAG から直接取得できます。

また、develop 時のマージ コミットに適切なメッセージを使用する場合、2 番目のケースでは、develop の最初の親を常にフォローすることで、変更ログを簡単に取得できます。ただし、2 番目のケースでは、最初の親のみをフォローする必要がある場合もあれば、複数の親をフォローする必要がある場合もあります。そして、コード化できることをいつ行うか、簡単な方法がわかりません。

4

2 に答える 2

3

git-flowそのようなことは何もしません。

これは、ここで説明する分岐モデルをサポートすることを目的としています(これは、Git 開発者が推奨する種類のものの実際の見栄えです)。その写真にはマージが含まれています。テキスト全体を通して同じことがわかります。ブランチの各タイプの下に、マージ先のブランチのタイプが表示されます。線形履歴--no-ffを強制的に回避し、代わりにマージコミットを記録するために使用するコマンドの例があります。

これは実際に Git を使用するワークフローであり、Git のコアの強みの 1 つは分岐とマージです。このワークフローはマージで成功します。非線形の歴史は避けられないだけでなく、望ましいものです。

ワークフローの説明から「完成した機能を開発に組み込む」というタイトルのセクションを読む必要があります。短い引用：

--no-ff フラグを指定すると、マージが早送りで実行できる場合でも、常に新しいコミット オブジェクトが作成されます。これにより、機能ブランチの歴史的な存在に関する情報が失われるのを回避し、機能を一緒に追加したすべてのコミットをグループ化します。

...

残念ながら、 --no-ff を git merge のデフォルトの動作にする方法をまだ見つけていませんが、そうすべきです。

それらのマージコミットが必要です。あなたは本当にそうします。

于 2012-01-10T17:57:17.587 に答える
0

MABJefromiは、歴史の中でそれを統合しても害がないということについて正しいです。

このコミットを回避する方法があります。これは、機能のマージを中央リポジトリにプッシュする1つ（ここではB）が、他のマージコミット（ここMA）を自分の履歴にマージしない方法です。代わりに、2番目のものはローカルマージcommit（MB）を破棄し、マージをやり直す必要があります。最初の親は現在ではなくC、最初の親のマージコミット（MA）です。したがって、2番目の開発者は、他のマージと独自のブランチ（new）を含むマージを作成しますMB。

個人的にはコミットについては気にしませんが、gitを初めて使用する人に無料の履歴をMAB取得するために必要なすべての手順を説明したくありません。MAB

于 2012-01-11T12:02:26.630 に答える