Photo Credit

Nitty gitties

My first encounter with “git” was a couple of years ago at my previous workplace. It took some time to understand it but I enjoyed working with git once I got comfortable with the concepts. By no means am I an advanced user of git, but I’ve tried to learn some tricks from my co-workers and mentors while working on different teams and projects. These tips and tricks have definitely made my life easier so I’m sharing them here in the hope that you might find it useful.

1) Work on the “branch” off the `master` for any task you’re working on and send the “pull request” from there

While working on a bug fix or a feature, especially in a team environment, create a branch from the master (or the branch which is considered as master) repository and work on it. Some engineers also prefer to work on their own fork and send a Pull Request from the fork once they’re done. Both the approaches have their pros and cons and it is up to the team to decide which strategy then want to follow. I personally prefer to work on the branch rather than the fork and here are some advantages I see with this approach

  1. Team members can know what others in the team are working on (Sneaky but ensures transparency :) )
  2. If some team member leaves the project in between, someone else can pick up their work (assuming the commits in the branch are up-to date)
  3. Small startups don’t need to get more accounts per person as they can share only one account (Frankly, I haven’t worked in a company or a project where you don’t get your own git account)

It is totally up to the teams and individuals to choose whichever approach (fork vs branch from master) works best for them. In both the cases, it is always recommended to work on branches .

For the examples in this blog, let’s assume that we are working on this cool new Calculator project. So for you to start contributing to the project, you’ll need access to this repository. Once you have it, clone the repository, create a new branch off the master and start contributing.

git clone

Make sure that the current branch is master

git branch -v

Now, if you want to start working on a feature to add subtraction utility, create a new branch called subtract

git checkout -b subtract

2) Make frequent commits on your local branch and keep pushing them

While working on a task, whether it a bug fix or a feature, keep making frequent commits. And also push those commits to your branch. At the end of the day, you don’t want to loose your hard work due to the hard drive crash after all.

Now lets say we added some cool stuff and made the commits to the branch. And our log looks something like this

3) Remove irrelevant commit messages by squashing your commits into one commit or few logical commits

Now, we’ve four commits but the point of interest is the end result ( or final code) and not different commit messages. For instance, why would a commit for fixing a typo deserve a special mention in git history after all ? We can squash the commits into a single commit so Git and the world thinks it is a single commit.

In this case, we want to merge the last 4 commits into a single commit, so we do

git rebase -i HEAD~4

On firing the above command, git will open up a vi editor and will look something like this

Hit I to go into Insert mode. Note that the commits are shown in ascending order. Pick the earliest commit and squash (Replace the word pick with squash) rest of the commits.

Note that you can also change the message for the commit you’re picking. Once you’re done with this, save your changes and quit (:wq). This will open up another vi editor where you can comment the messages (By putting # at the beginning of the line) you don’t want to show up in your history.

Once you’re done, save and exit (:wq). You will see something like

Now, if you see the logs again , you should see only one commit.

Hurray !!! We successfully squashed the unwanted commits.

Now, the phase 1 of your feature is working and well tested and when you send the PR, Git will show only one commit.

4) Pull changes from master by using rebase option

You continue working on the feature for the next phase. Once your code is in the master, other contributors can also start working on the same code. Let’s assume someone found a bug in the subtraction code and they sent a fix for it, which is reviewed and merged into master. So you’ll need to pull in changes again to be in sync. In this case, don’t do regular git pullbut always prefer git pull with rebase option. This will ensure that you pull in the changes from the master and then your local changes will be applied on top of it.

git pull --rebase origin master

If someone else has modified the same files or code you’ve been working on, you will see conflicts. In this case, you’ll need to manually fix the conflicts before continuing with rebase.

In my editor, I saw these conflicts

This was an easy fix and I went ahead and fixed the conflicts

Once you fix the conflicts and you’re comfortable with your changes, you need to add the changed files.

5) Follow ‘separation of concerns’ principle with commits

While developing a feature A, don’t add the code for feature B with the same commit or don’t make a unrelated bug fix along with it. You can accomplish this by using different branch for each bug fix or commit. This also helps to keep your pull requests concise and precise.

6) Tidy up

Less clutter the better — right ? Once a pull request is merged to your master , delete your branch. You can do it from the Github UI.

These are few of the practices I have been following while working with Git and has yielded rich dividends in terms of productivity. I’ll keep on adding to this list as and when I find something useful. Please feel free to comment on this blog or reach out to me if you’ve any suggestions. Happy Gitting !