Great write up on crucial concepts to understanding how/why to use various git commands. There is one semantic distinction that I find helpful when talking about rebase to those unfamiliar with it. Rather than saying:
We re-base our add_patrick branch on the current state of the master branch.
It might be clearer what is happening if you say:
We re-base our add_patrick branch from the current state of the master branch.
That is to say, we get a new base set of commits for our branch from another branch. So, as you describe, when we run the command git rebase master [add_patrick], we are taking all commits frommaster that add_patrick does not yet have, and rewinding to apply them to HEAD before replaying our commits in add_patrick.
For me personally understanding the on or onto wording for rebase as it's also used in the git reference actually helped me when I learned about it originally.
I take my changes, which where originally based on some branch HEAD, and I put them onto some other branch's current state (or state of the same branch)
Agreed - I completely misunderstood this at first because “rewind and rebase onto” sounds like “take my work from ‘add_patrick’, add all those commits “onto” ‘master’ (which doesn’t happen & wouldn’t really make sense) before moving the divergence point & continuing on the current branch.
The key point to understand is that you get all new commits from ‘master’ so your current branch is up to date with it (kinda like a git pull), then reapply the commits from ‘add_patrick’ again from that new point of divergence from master, but still on ‘add_patrick’ itself.
That confusion on my part aside, I found this to be a fantastic overview! Thanks!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great write up on crucial concepts to understanding how/why to use various git commands. There is one semantic distinction that I find helpful when talking about
rebaseto those unfamiliar with it. Rather than saying:It might be clearer what is happening if you say:
That is to say, we get a new base set of commits for our branch from another branch. So, as you describe, when we run the command
git rebase master [add_patrick], we are taking all commits frommasterthatadd_patrickdoes not yet have, and rewinding to apply them to HEAD before replaying our commits inadd_patrick.Now i get it...thanx
For me personally understanding the
onorontowording for rebase as it's also used in the git reference actually helped me when I learned about it originally.I take my changes, which where originally based on some branch HEAD, and I put them
ontosome other branch's current state (or state of the same branch)Like I said, it is semantics, but I've found that slight change in wording useful for some when helping them understand
rebase.Agreed - I completely misunderstood this at first because “rewind and rebase onto” sounds like “take my work from ‘add_patrick’, add all those commits “onto” ‘master’ (which doesn’t happen & wouldn’t really make sense) before moving the divergence point & continuing on the current branch.
The key point to understand is that you get all new commits from ‘master’ so your current branch is up to date with it (kinda like a git pull), then reapply the commits from ‘add_patrick’ again from that new point of divergence from master, but still on ‘add_patrick’ itself.
That confusion on my part aside, I found this to be a fantastic overview! Thanks!