Clever Geek Handbook

Maintaining a branch that does not contain commits associated with a specific change

I am working on a project with Git and have come to the point where I would like to split development into two separate branches. The split is about a simple change (with capital C, so I can come back to it later) that touches on one isolated piece of the codebase - on one branch, I want Change to be present; in the other, no. The change is wrapped in one commit.

In the branch master

where I do all my coding (unless a specific topic appears), this is the branch I want to change to. I would like to create 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 main, preferred branch: on the branch, I will continue coding, and that's the branch that I am actually executing. I want to save original

just in case I need a version of the code without the above change later.

Here's the problem: I would like to be able to "merge" work from master

in original

on the way, but obviously only commits that don't touch the change.

  • If I make it simple git merge master

    , it original

    goes into mode master

    by introducing a change I didn't want, right?
  • I do not want to develop on original

    and merge with master

    , because this original

    is a special case, not master

    .
  • I don’t want cherry-pick

    out master

    , because it will confuse my development history.
  • I can create a new branch develop

    from the command that types Change in master

    . I could commit non-change commits on this branch and merge them into master

    or easily original

    . However, if I make some change-related commits to master

    and want to merge them into develop

    , then I can't safely merge develop

    into again original

    , right?

I would like to know your opinion on the best way to proceed.

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

+3


source to share


2 answers


How about branching from master to upstream, and then git revert

commits that contain changes you don't want to maintain on the upstream branch. I think it git merge

will work then. It's just that the sum of multiple even commits will be zero.



+3


source


I liked the fourth approach:

I would recommend that you create another branch hotfix

from which you created the branch original

. Both branches will not contain Change

associated commits, and you can safely merge them into a branch master

and original

.

If you want to merge some related Change

commits into master

c hotfix

then create a branch hotfix-with-change

from hotfix

and merge it there.



If you want to develop unrelated code Change

that will affect original

and master

, do so in hotfix

and don't forget to update the branch as well hotfix-with-change

.

If you want to develop related Change

code, your branch must be a branch master

, and if you want to see it make a mistake in original

, you need to merge it with hotfix-with-change

.

Hope this was clear.

+1


source






More articles:


All Articles