16

マスターブランチの機能をきれいにマージするために使用したいと思いますgit rebase（コミット数を減らすか、少なくとも変更ログの先頭で）。リポジトリで作業しているのは私だけであることに注意してください。

Gitワークフローとリベースとマージの質問を読んだ後、私はかなりいいと思いました。ミカのように、さまざまな場所（ノートブック、自宅、別のPCなど）から変更をリベースgit rebaseしたいのです。 ..）git push

したがって、ここに2つの解決策があります（双方向の醜いマージに対する）：

  1. を使用git push -fしてプッシュしてから他のマシンをプルしますが、他のマシンで最新バージョンをクリーンに取得するにはどうすればよいですか？
  2. マージを使用してマスターの変更を機能ブランチにマージし、git push / pullし、成熟したら、単一のリベースを実行します（1つ以上のコミットでクリーンに）

（2）以下のようになります：

git co -b feature-a
... change files
git push origin feature-a
... moving to another PC
git pull origin feature-a
... change files
git merge master
... change files (not the "special rebase")
git rebase master
git co master
git merge feature-a
git branch -d feature-a
git push origin :feature-a

どの解決策がうまくいくと思いますか？私はこれまでどちらも試していません（主にログが乱雑になることを恐れて）。

4

2 に答える 2

13

私は常に、離れるマシンからすべてをコミットしてプッシュ（-f）するようにします。

他のマシンに到着したとき：

 git fetch -v
 git checkout mybranch # Already checked out with old HEAD
 git reset --hard origin/mybranch

これは、別のコンピューターにいる他の「私」が、離れる前に一貫してコミットしてプッシュすることを知っているため、うまく機能します（したがって、到着したマシンにプッシュされていない変更はありません）

于 2010-02-08T06:56:06.597 に答える
11

git rebase変更を再生し、新しいコミットを作成することを忘れないでください。リベースしてプッシュをあちこちに強制することで、ツールの粒度に逆らうことになります。ドキュメントの「アップストリームリベースからの回復」セクションがどのように始まるかに注意してくださいgit rebase（さらに強調して）：

他の人が作業に基づいているブランチのリベース（または他の形式の書き換え）は悪い考えです。その下流にいる人は、手動で履歴を修正する必要があります。このセクションでは、ダウンストリームの観点から修正を行う方法について説明します。ただし、実際の修正は、そもそもアップストリームのリベースを回避することです。

あなたが唯一の開発者であるとしても、他のクローンで作業するときは、（1つのリポジトリの観点から）他の人になります。ご覧のとおり、このワークフローは面倒です。

あなたの変更を枝で調理しましょう。ブランチがプライムタイムの準備ができたら、リベースし、マスターにマージして、トピックブランチを削除します。ブランチの存続期間を短くし、その範囲を狭くすると、人生が最も簡単になります。

于 2010-02-08T05:01:19.543 に答える