3

I'm working on a project with Git and have come to a point where I'd like to break development into two separate branches. The split concerns a simple Change (with a capital C so I can refer back to it later) that affects one isolated part of the codebase -- in one branch, I want the Change to be present; in the other, I don't. The Change is encapsulated in one commit.

The master branch, which is where I do all my coding (unless a specific topic comes up) is the branch that I want to contain the Change. I'd like to make a separate branch, original (or whatever you want to call it), that does not contain the Change.

master, the branch with the Change, will remain the primary, preferred branch: that's the branch I'll keep coding on and that's the branch whose code I'll actually run. I want to keep original around just in case I need a version of the code without the aforementioned Change later.

Here's the problem: I'd like to be able to "merge" work from master into original down the road, but, obviously, only the commits that don't concern the Change.

  • If I do a simple git merge master, original will fast-forward to master, introducing the Change I didn't want, right?
  • I don't want to develop on original and merge to master, because original is the special case, not master.
  • I don't want to cherry-pick from master, because that's going to muddy up my development history.
  • I could make a new branch, develop, from the commit that introduces the Change in master. I could make non-Change-related commits on this branch and easily merge them into master or original. However, if I make some Change-related commits on master and want to merge them into develop, then I'll again be unable to safely merge develop into original, right?

I'd like to know your opinions on how best to proceed.

EDIT: I'm the only person working on this project, so don't rule out a solution because it may mess up other programmers in a collaborative setting. I'm just looking for an easy-to-use solution that produces a clean, intuitive history that captures what these different development histories really are. If no such solution exists, I'll accept one of the answers that get the job done.

4

3 に答える 3

3

マスターから元のブランチに分岐してから、元のブランチでgit revert維持したくない変更を含むコミットはどうですか。私git mergeはそれからうまくいくと思います。いくつかの偶数コミットの合計がnullになるだけです。

于 2013-02-08T16:37:57.703 に答える
1

私は4番目のアプローチが好きでした：

hotfixブランチを作成した場所から別のブランチを作成することをお勧めしますoriginal。両方のブランチには関連するコミットが含まれないため、安全にブランチChangeにマージできます。masteroriginal

Change関連するいくつかのコミットを でmasterマージしたい場合は、からブランチをhotfix作成してそこにマージします。hotfix-with-changehotfix

Change関係のないコードを開発したい場合は、それが影響originalしmaster、ブランチhotfixを更新することを忘れないでください。hotfix-with-change

Change関連するコードを開発したい場合、ブランチはmasterブランチである必要があり、そのコミットを で確認したい場合はoriginal、そのコミットを とマージする必要がありますhotfix-with-change。

私はそれが明らかだったことを願っています。

于 2013-02-08T16:50:25.853 に答える
0

ここに問題があります: マスターからオリジナルに作業を「マージ」できるようにしたいのですが、明らかに、変更に関係のないコミットのみです。

開発履歴がごちゃごちゃになるので、master からチェリーピックしたくありません。

マスターからマージしたくない場合、およびチェリーピックしたくない場合は、それgit rebaseが唯一のオプションです。

A--B--C  (master)
       \
        X--Y--Z  (original)

D E Fアップストリームの変更はどこにありますか

A--B--C--D--E--F
       \
        X--Y--Z

X Y Z「悪い」コミットを元に戻しています。

A--B--C--D--E--F
                 \
                  X'--Y'--Z'

参照

于 2013-02-08T16:52:34.533 に答える