CODEWITHSUNDEEP
gitgit-branch
jobo3208
jobo3208

Reputation: 842

Maintaining a branch that doesn't contain commits relating to a certain change

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.

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.

Upvotes: 3

Views: 102

Answers (3)

Zombo
Zombo

Reputation: 1

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.

I don't want to cherry-pick from master, because that's going to muddy up my development history.

If you don't want to merge from master, and you don't want to cherry pick, then git rebase is your only option.

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

where D E F are upstream changes

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

and X Y Z are undoing the "bad" commits.

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

ref

Upvotes: 0

ogzd
ogzd

Reputation: 5692

I liked the fourth approach:

I would recommend you to create another hotfix branch from where you have created original branch. Both branches will not contain Change related commits and you can safely merge them into master and original branch.

If you want to merge some Change related commits at master with hotfix, then create hotfix-with-change branch from hotfix and merge it to there.

When you want to develop a non Change related code, that will effect original and master, do it in hotfix and don't forget to update hotfix-with-change branch as well.

When you want to develop a Change related code, your branch should be master branch and if you want to see that commits in original, you need to merge that commits with hotfix-with-change.

I hope It was clear.

Upvotes: 1

Gaurav Agarwal
Gaurav Agarwal

Reputation: 14843

How about branching off from master to the original branch and then git revert the commits which contain the changes you don't want to maintain in the original branch. I guess git merge will work then on. Just that the Sum of a few even commits would be null.

Upvotes: 3

Related Questions