Git Series (4) — Cleaning up before Pull requests

Expectation

In an ideal world, One should be able to identify the product maturity model by merely looking at the commit logs for the main/master branch in the git. But it's possible only if, each commit represent a feature Featureor change or bugfix or at least for an incremental atomic change.

Problem

Having only meaningful commits directly contradicts what I call as “no code left behind” principle. Developers shouldn’t leave any code on their development machines. Instead, the code should be committed and pushed to the remote repo, every day before logging off.

But sometimes one day is not enough to complete even incremental atomic changes suitable for a PR, let alone the code for the full feature. In those cases, this everyday push to the remote repo brings a lot of commits in the final Pull Request aka PR.

In this post, I will show how can we combine all these commits before raising a PR, or as they call MR in GitLab.

Solution

There are two ways, I’ve used in the past to combine commits. One is by using rebase and another by reset.

NOTE — both these processes change commit history in the remote repo. So DO NOT use anything explained below if you are working on a shared branch (branches where other developers also push & pull the code). 
All this should be used to fix the commits on the branches, only you are working on.

Let's create the problem

Setup a repository

Let's create a local git repo and add a README file in the master branch.

mkdir git-prs && cd git-prs && git initecho “#Git PRs” >> README.md && git add README.md && git commit -m “first commit”

Let's create a repository named git-prs in your GitHub account & push the code to remote.

git remote add origin git@github.com:<your-user/org-id>/git-prs.gitgit push -u origin master

A slow developer — Multiple pushes, No PR

Let's assume, a user story was assigned to me to add a few lines of description to the project readme file. 
Because of my development speed, I am able to add only one line a day. And I push my code to the remote repo every day before logging off from work.

Here are the steps

//Day-1
git checkout -b feature/readme-descriptionecho "Line 1" >> README.md && git add README.md && git commit -m "Added description in readme" && git push -u origin HEAD//Day-2 
echo "Line 2" >> README.md && git add README.md && git commit -m "updated description in readme" && git push origin HEAD//Day-3
echo "Line 3" >> README.md && git add README.md && git commit -m "Line-3 description in readme" && git push origin HEAD

On day 4, when I tried to create the PR, I realized I have these 3 commits for just one logical change. This will clutter the final project history

So here are the steps I can take to make my PR look good

Squash commits using Rebase

We want to meld the last 3 commits into one, so we will do the interactive rebase on the 3 commits prior to HEAD using the following commands

git rebase -i HEAD~3

Once you press enter, the following content will show up in whichever editor is configured in your git.

Content of this file

The lines prefixed with # are the comments for some help documentation provided by git. The remaining lines at the top are the commits that we want to work on during this rebase.

NOTE- Unlike git log, in the rebase output the latest commit is displayed at the bottom and the oldest at the top.

Each line has the following 3 records.
<rebase-action> <commit-hash> <commit-description>

For our use case, only the following 2 rebase-actions are needed.

1. fixup (f) to meld mentioned commit into the previous commit and ignore mentioned commit’s message
2. reword (r), To change mentioned commit’s message.

So, in my editor, I will write either f or fixup (both work same) in front of the commits I want to meld. Here is what my final file will look like.

Save this file and you will get such a message.

NOTE- You might not see a successfully rebased message if you’ve contradictory changes between melding commits. In that case, you will resolve conflicts as you usually do. I try to avoid such melds.

We’ve changed commit history, so we will not be able to push the local repo to remote. So we’ve to use force push

git push -f origin HEAD

Now I can go back to Github and raise my nice-looking PR

Rewriting new commit using Reset

If you’ve read my second post in the git series, you might remember, how git reset -— <option> <pointer> affects repo-tree, staging-area, & working-treedifferently, when used with different options.

For our use case where we’ve 3 commits that we want to meld into one, we will do a soft reset on HEAD, going back to 3 commits.

• To verify, run the command git log. you should see 4 commits. a first commit, followed by 3 commits where we changed the readme.
• run git reset — -soft HEAD~3
• Run the command git log again. Now you should see only the first commit. However, when you open the readme file, you will see all the changes from the last 3 commits are preserved.

So now we’ve all our changes in the staging area and no commit in the repo tree. All we need to do now is to commit these changes with a clean commit message and push them to the remote repo (force push)

git commit -m "Adding Readme description"git push -f origin HEAD

Now go ahead and raise a PR on GitHub.

Conclusion

That's all we had for this topic, but before I close, Two things to note here are

1. We are using a force push to remote. Avoid it if you do not completely know what you are doing.

2. Avoid using rebase or reset when you have merged or rebased commitsin between the commits you want to meld.