Featured Image: “Forest” by fear-sAs is licensed under CC BY-NC-ND 3.0
In my previous post we looked at some basic git commands. Let us delve a little deeper into branches.
A branch in git is really just a pointer to a commit
Head points to the current branch which in turn points to the latest commit in a branch.
Same image as earlier but now with reference to HEAD - For nore details refer Git Branching Branches in a Nutshell
Integrating changes between branches
Two main ways to get changes from branch to another.
As more people start working in the same project, there will be multiple contributions made throughout the day. All these will be done from individual branches and we have to get all the changes in those individual branches into the main repository’s main branch, usually named
main these days).
Now if the pull request was accepted and hotfix merged into
main. But you are still working on
Finally you create a pull request after you have completed working on
iss53, this has to now go into master as a merge-commit.
That’s a merge operation in action.
- Common scenario:
- Working on a feature for more than a day while others have committed and merged to master
- So you want your feature to be the last one on master
When not to rebase?
- Rebasing abandons commits and creates new ones that are similar but different
- If you are collaborating on a feature and sharing the same branch with another person
- Do not rebase until both sides have completely merged changes into the common branch
- If you rebase and push in between, you are killing collaboration
- Every time you rebase and (force) push, you create new commits that didn’t exist in the collaborators’ local branch, forcing your fellow collaborator(s) to murder you or quit and move on. Okay that’s a bit extreme, but you know.
This is how you do a rebase interactively on the command line.
Quite often when you are doing a rebase onto a main branch, you would want to squash your commits. Squashing means, combining several commits into one so that your changes don’t look like a mega list of changes. You would want to do this in order to make your main branch’s history look concise.
Nobody wants to know how many times you missed a semi-colon or a comma. However, most people would want to know a one-line description of what feature went into main branch.
Gives a really good summary of the options available to you and explains rebasing in detail.
Git Branching and Rebasing documentation gives a really good summary of the options available to you and explains rebasing in detail.
Let us learn more about some additional helpful commands that could save you from tricky situations in the next post.