Search code examples
gitazure-devopsversion-control

git rebasing for linear history

I have an issue with being unable to create a "linear" history for my branch using rebase.

I may have a wrong concept as to what can/should be done, but this is what am working with:

---A---B---E   master
       |
       |---C---D  feature

At this point both branches (master and feature) are synced with their remote counterparts, meaning that both the local and remote repositories have these commits. At this point I ran:

git checkout feature
git pull --rebase origin master

at this point, since rebase is local not remote, before I can git push i have to git pull (and i think herein lies the main issue). So a git pull and git push later and what I expected was the following:

---A---B---E---C'---D'---MergeCommit---

But instead I end up with:

---A---B--------------------C---D---MergeCommit---
       |                            |
       |---E---C'---D'--------------|

Note: I am not sure if the C and C' are correctly placed, as i have no way of telling which of these two was the original and which is a "copy" but there are two of them present.

You can see the picture below to make it more clear.

enter image description here

Now, I do not mind having two "lines" here, for the lack of a better word. I do not mind having a "merge commit". All of this is fine. What drives me crazy is the duplicating of commit C and commit D.

Or even the following would be still be acceptable:

---A---B-------------------MergeCommit---
       |                   |
       |---E---C'---D'-----|

How do I get rid of them, on either of the "lines". I keep saying lines because all of this is a single branch. I've not dabbled with version control for a few years now, i am pretty sure this was not the behavior back when I did, and i didnt have duplicated commits, instead they were a single linear graph. I would blame git pull because of the message that i get now, which i do not recognize, Merge made by the 'ort' strategy. this seems new to me and i feel like it is the reason for the issues.

Solution

  • NOTE: I've only used this workflow with non-shared feature branches. OP mentions they have a different use case (see comments), so they would have to adapt this workflow or use a different one.

    I've mocked up a repo similar to yours: I've got a feature branch 'feature'/eabd641 originally branched off of local 'master'/5d2cce8. After git fetch --all, we see the remote 'master' branch has advanced to new commit 82e4b59.

    * eabd641 Mon Jul 29 12:01:01 2024 -0400 test 1
|  (origin/feature, feature)
| * 82e4b59 Sun May 5 23:15:23 2024 -0400 Fix bug
|/   (origin/master)
* 5d2cce8 Sun May 5 21:54:15 2024 -0400 3/3 challenges
|  (HEAD -> master)
* f0994f1 Sun May 5 18:06:48 2024 -0400 2/3 challenges

    If I apply the command OP used

    git checkout feature
git pull --rebase origin master

    My repo now looks like this. My feature branch was rebased onto remote tracking 'origin/main'/82e4b59 (my local 'master' was not updated). The feature is now linear because it is off the tip of (remote) master, but my remote tracking branch 'origin/feature' is now out of sync due to the rebase. The 'test 1' commit exists in local and remote feature branches - a git pull now would merge to local and remote which keep both 'test 1' commits in the history as OP saw.

    * b1f6f71 Mon Jul 29 12:01:01 2024 -0400 test 1
|  (HEAD -> feature)
* 82e4b59 Sun May 5 23:15:23 2024 -0400 Fix bug
|  (origin/master, origin/main)
| * eabd641 Mon Jul 29 12:01:01 2024 -0400 test 1
|/   (origin/feature)
* 5d2cce8 Sun May 5 21:54:15 2024 -0400 3/3 challenges
|  (master)
* f0994f1 Sun May 5 18:06:48 2024 -0400 2/3 challenges

    While still on my local feature branch, I would now git push -f to sync the remote 'feature' branch with the rebase, then do a build and run tests to code is good, do one more fetch to check the remote 'master' hasn't advanced again, then git checkout master, git pull and git merge feature (this will fast-forward - add --no-ff if you want a merge commit). Finally, do a git push of master (normal push, not a force push).

    Not sure I like using 'git pull --rebase origin master' to combine a pull and rebase to rebase the feature onto the tip of the remote tracking 'origin/master'. I would rather be first update local 'master' and then explicitly rebase 'feature' onto my local 'master', then git push -f. You need to update the local 'master' at some point anyway.

    Aside: Something I do when learning new git commands or learning a new workflow: look at the git tree before each command, predict what it will look like after, run the command, and then look at the git tree after. Any time it didn't do what you expected, did deeper into why - did I use the command wrong or use the wrong args or did I misunderstand what the command does?

    Also, have a good git log alias to make visualizing the git tree easy - Pretty Git branch graphs