2

I have git timeline like this:

  1. master
  2. feature-1 -> merged (to master)
  3. feature-2 -> merged (to master)
  4. feature-3 -> merged (to master)

All those features happen sequentially (First feature-1. Once it's completed finished, then feature-2, and so on).

Feature-2 is "conflicting" with Feature-1. Conflicting not in the sense of git conflict, rather featurewise.

enter image description here

Now the client decided they prefer feature-1, so we need to pull it back from the dead.

What is the safest and most efficient way to have a new branch that includes feature-1 + anything else in master (feature-3 in this case), excluding feature-2 ?

One alternative I come up with is:

  1. git checkout feature-1
  2. git checkout -b yeahbaby
  3. git merge feature-3

But then you need to know all the branches (in this case it's easy, only feature-3). But in real case you have many of them.

EDITED: beside, it wouldn't work... becase feature-3 is based of master, which carries all the changes in made in feature-2 (which has been merged to master).

Cokorda Raka
  • 4,375
  • 6
  • 36
  • 54
  • are all features started from the same commit? maybe a visual graph will help us – Sysix Oct 25 '18 at 17:08
  • No, it happens sequentially. First there is master, then feature-1 then merge, then feature-2 then merge, and so on. – Cokorda Raka Oct 25 '18 at 17:11
  • I edited the original question to clarify it based on your question. – Cokorda Raka Oct 25 '18 at 17:18
  • Could you not revert the feature-2 merge? – Oliver Charlesworth Oct 25 '18 at 17:32
  • @oliver: I don't think so... But let me understand, so what should do here is: 1. git checkout feature-2 2. git checkout -b yeahbaby 3. git reset --hard 4. git merge feature-3 ? But than it would the same as the other alternative; need to know all the branches from feature-3 onward. – Cokorda Raka Oct 25 '18 at 17:43
  • 1
    Not quite - I'm saying that starting from master, you'd simply do `git checkout -b yeahbaby`, `git revert -m 1 `, `git commit -m "Revert feature-2"`. (See https://stackoverflow.com/questions/7099833/how-to-revert-a-merge-commit-thats-already-pushed-to-remote-branch) – Oliver Charlesworth Oct 25 '18 at 18:36

1 Answers1

0

There is no "safest way" to create a new git history that misses one feature from the original history.

The two most likely possibilities are:

  • Create a branch at master, and git revert <commit_id> with any commit you want to revert (ideally in reverse order). This will undo the changes made in the past as good as possible. It is relatively easy, but will become more complex the further in the past the reverted commits were
  • Create a branch at master, do a git rebase interactive <merge1_commit> and remove all commits that you want removed. This replays the history, and you could run tests after each rebase commit to ensure each step is valid. However this will flatten the history and you may have to repeatedly fix merge commits.

Outside git you can consider the possibility of adding a feature-toggle for the given feature, so that all customers get the same codebase, but for some customers a feature will be disabled via configuration. This would make moving forward with 2 branches somewhat easier in some cases.

tkruse
  • 10,222
  • 7
  • 53
  • 80