4

私の開発ブランチを master ブランチにマージすることについて少しアドバイスが必要です。また、Git 拡張機能を使用していることにも注意してください。可能であれば、コマンド ラインの専門用語を使いすぎないようにしてください。

devブランチで 3 つのコミットを行ったとします (そして、現在もチェックアウトしており、mstブランチには、分岐した時点から 1 つのコミットがあります。

dev:    1 ---> 2 ---> 3
       /
      /
mst: 0 --- X

今、開発ブランチをmstブランチにマージしたいのですが、実際にはコミット 1 と 2 だけをマージしたいのです。

私の理解では、mstをチェックアウトし (進行中の作業のために事前に一時コミットをスタッシュまたは作成する)、mstを commit 2 とマージする必要があるということです。

dev:    1 ---> 2 ---> 3
       /        \
      /          \
mst: 0 --- X ---- 4

現在、コミット 3 は同期していないため、次に行うことはdevブランチを再同期することです。これを行うには、devをチェックアウトし、 dev を mst とマージするか、devをmstにリベースする必要があります。

すなわち。

dev:     1 ---> 2 ---> 3 --- 5
        /        \          /
       /          \   ------
      /            \ /
mst: 0 ---- X ----- 4

また

dev:    1 ---> 2     5
       /        \   /
      /          \ /
mst: 0 --- X ---- 4

他の開発者とうまくいかない主な問題は、マージが膨大な時間の浪費になる可能性があることです。

  1. 現在の作業を「保存」し、mstをチェックアウトしてから、 devをチェックアウト する必要があります (VB6 を使用しているため、マージの競合が発生する可能性があり、VB6 が認識しないため、ファイルをリロードするために VB6 を閉じてから再度開く必要があります)。外部で変更されたファイル)
  2. 二重マージ プロセス (1 つはmstを更新 し、もう1 つはdevを再同期する)

また、私は stash でいくつかの信頼性の問題を抱えていました (時々、stash pop がポップを妨げます)。そのため、仲間の開発者に一時的なコミット (コミット 3 の後) を行い、最後に混合リセットを行うことをお勧めします。 .

私たちは小さな会社なので、できるだけ早くリリースすることが優先事項です (ただし、一部のリリースは保留されているため、すべてを公開することはできません)。これほど多くの手順が実際に必要ですか、それとももっと速い方法がありますか?

4

4 に答える 4

1

ブランチを使用する

コメントで示唆されているように、これを行う最も簡単な方法は、2 回目のコミットの後に新しいブランチを作成することです (コミット #3 の変更に取り掛かる直前のように)。

このようにすると、さらに作業を行っても、きれいなマージ ポイントが得られます。

あなたのワークフローは、集中型 VC での以前の経験に影響されているようです。信頼できるレポにブランチ「master」(mst) または「develop」(dev) があるからといって、それらを同じように呼ばなければならない、または 1 対 1 の対応が必要であるとは限りません。

git では、有効期間の短いブランチ (どんな名前でも) を作成し、パブリックまたは正式なリポジトリにプッシュするときに適切なブランチをマージする方が簡単な場合が多いと思います。

于 2013-02-18T10:42:02.733 に答える
0

使用しているツールは何ですか？私はgithubにMacクライアントを使用しています：

http://mac.github.com/。

この優れたツールを使用すると、分岐、マージ、分岐間の変更は30秒の操作で済みます。もちろん、あなたは非常に高い抽象化レベルで作業しますが、日常の使用にはそれが私が必要としているものです。

Windowsのバリエーションもありますが、使用したことがなく、制限があるかどうかもわかりません。

http://windows.github.com/

主に3つのレベルのソース管理ツールがあります。

1）VSSスタイルのブロックされたチェックアウト：これは歴史的な方法です。同じファイルを同時に処理しない開発者が1人いる場合は、これでうまくいく可能性があります。

2）SVNスタイルのノンブロッキングチェックアウト：すべての開発者は中央リポジトリで作業しますが、同じファイルで同時に作業する場合があります。競合がある場合は、コミットする前に解決する必要があります（コミットする前に更新/解決）

3）Gitスタイルの分散SCM：これは、ローカルリポジトリを使用して独立した開発を長期間行う開発者がいる場合に最高の価値をもたらします。結果に満足したら、変更を親リポジトリに公開することを決定できます。主にオープンソース開発に使用されます。

開発スタイルに最適なモデルを選択する必要があります。緊密に連携しているチームを持つほとんどの商業組織にとって、SVNモデルは非常にうまく機能します。より複雑な開発チームがある場合は、Gitがそれに対処するのに役立つ場合があります。

于 2012-07-15T01:36:27.723 に答える
0

Git では、マージ操作中に作業ディレクトリとインデックスを使用する必要があります。これは、発生したマージの競合を解決するためにそれらが必要になるためです。

マージ中に作業ディレクトリをダーティな状態に保つ必要がある場合は、プライマリ ローカル リポジトリをオリジンとして使用してクローン リポジトリを作成できます。次に、クローンですべてのマージを行い、変更をプライマリ リポジトリに戻します。

Git 拡張機能を使用してクローンを作成するか、次のようなコマンドを使用できます。

cd C:\Users\Basewq\Code
git clone MyProject MyProjectForMerging

次に、作業ディレクトリを中断せずにマージを実行したい場合は、変更を MyProject から MyProjectForMerging にプルし、マージを実行してから、コミットを MyProject にフェッチします (警告: 変更を MyProject にプッシュしないでください。常にフェッチ/プルします)。ここでも、Git 拡張機能を使用するか、コマンド ラインを使用できます。

cd C:\Users\Basewq\Code\MyProjectForMerging
git checkout mst
git pull
git merge dev

変更をプライマリ リポジトリに戻すには、次のようにします。

cd ..\MyProject
git fetch ..\MyProjectForMerging

これで、コミットは MyProject リポジトリに配置され、オリジンまたはどこにでもプッシュ バックできるようになります。必要に応じて、MyProjectForMerging から他のリモートにプッシュすることもできます。

于 2012-07-15T07:46:54.210 に答える
0

Git では、マージ操作中に作業ディレクトリとインデックスを使用する必要があります。これは、発生したマージの競合を解決するためにそれらが必要になるためです。

マージ中に作業ディレクトリをダーティな状態に保つ必要がある場合は、代わりの作業ディレクトリとインデックスを一時的に使用するように Git に指示できます。ただし、これにはコマンド ラインが必要であり、混乱を招く可能性があります。

目標は、一時インデックス ファイルと一時作業ディレクトリを作成することです。Git をそれらにポイントし、マージを実行してから、通常のインデックスと作業ディレクトリを復元します。

:: Create a temporary working directory, but use my normal repository

mkdir C:\Temp\MyProject
set GIT_DIR=C:\Users\Basewq\Code\MyProject  -- (path to my normal repo)
set GIT_INDEX_FILE=C:\Temp\index
set GIT_WORK_TREE=C:\Temp\MyProject

:: Now do the merge in C:\Temp\MyProject

git checkout mst
git merge dev

:: Now put everything back

set GIT_DIR=
set GIT_INDEX_FILE=
set GIT_WORK_TREE=
del C:\Temp\index
rd /q /s C:\Temp\MyProject
于 2012-07-15T08:04:41.387 に答える