8

The question is about some edge case of git-flow methodology

I have some kind of typical git-flow history like this:

      o---o---o---o [release-3.5.0]
     /
----o---o---o---o---o [development]

Git-flow told us to merge release-3.5.0 branch into development then release is ready. So, eventually we'll get ALL changes, made at release branch into development branch.

      o---o---o---o 
     /             \
----o---o---o---o---o [development]

Now imagine, we have a commit 'X' on release branch what we DO NOT want at development branch, for example it is some kind of hack/hotfix or else which is already fixed in development in more sane way (i.e. by commit Y)

      o---X---o---o [release-3.5.0]
     /
----o---o---o---Y---o [development]

So, the main question is how to deal with such situations? How to prevent this commit (or commits) from getting back into development?

Olegas
  • 10,349
  • 8
  • 51
  • 72
  • 1
    Possible duplicate of [git - skipping specific commits when merging](http://stackoverflow.com/questions/727994/git-skipping-specific-commits-when-merging) – Ilya Serbis Oct 28 '15 at 14:21

3 Answers3

7

While the answers recommending rebase and/or merge/revert/squash will work, I personally think the better answer would be this:

git checkout development
git merge --no-commit release-3.5.0
# make whatever changes you need to fixup the "hack" and/or clean up any conflicts
git commit
twalberg
  • 59,951
  • 11
  • 89
  • 84
  • The `--no-commit` doesn't generate 'merge info'. Release branch will not shown in history as merged, not it will treated as merged by command like `git branch --merged`. So, one can accidentally merge it once again by mistake. – Olegas Jun 24 '13 at 15:06
  • 2
    @Olegas While your comment is technically correct, following the above complete workflow *will* create "merge info" (assuming by that you mean some combination of the merge-formatted commit message and/or the parent pointers that create a merge in the history DAG), but it is the final `git commit` that creates those. The `git merge --no-commit` just sets things up so that the appropriate meta data will be created. If you try `git branch --merged` before the final `git commit`, it will correctly show that the branch hasn't been merged yet, because the merge hasn't been committed... – twalberg Jun 24 '13 at 15:26
  • 1
    yes, you are right. After commit all is fine, including merge info, I was wrong. – Olegas Jun 24 '13 at 18:40
3

In such scenarios you always want to fully merge the release(-like) branches. So make sure nothing is missing.

But during the merge you can freely modify the content -- including to drop or redo some changes. For your example case, merge the branch, revert the commit you don't like, and squash that revert into the merge commit. Obviously make a note in the merge commit message of that action.

If the fix is already on devel, merge will just skip over it, or you resolve the conflict by selecting the devel version.

The point is you want the history show as your second figure, and the state as it makes best sense.

Balog Pal
  • 16,195
  • 2
  • 23
  • 37
1

You have several options :

1) use git rebase -i

In this mode you can rebase your release branch on your development branch and exclude the Xth commit.

Warning You will mess the existing cloned repositories in this case.

2) use git cherry-pick

In this mode you will have the possibility to pick commits one by one.

3) use git rebase -i on a separate branch and merge it afterwards, as specified in this answer : Is it possible to exclude specific commits when doing a git merge?

Community
  • 1
  • 1
StKiller
  • 7,631
  • 10
  • 43
  • 56
  • `rebase` is not suitable cause' the warning you noted, `cherry-pick` is acceptable but too complicated cause' release branch I have has too many commit (but it can be automated somehow). – Olegas Jun 24 '13 at 11:23
  • 1
    cherry-pick actually allows picking of a range of commits ( http://stackoverflow.com/a/1994491/696792) , but this includes some issues too ( specified in the linked answer ) – StKiller Jun 24 '13 at 11:27
  • Updated the answer with third way. – StKiller Jun 24 '13 at 11:30