Staging Commits with “Git Add Patch”
As a developer, there are few things more exciting than starting a new project. The process of drawing a domain model to map out your backend logic, creating a front-end wireframe to decide the layout of how it will look in the web-browser or mobile device, and then finally writing the code to bring your vision to life can be exhilarating. In the past when I have started working on new projects it was easy to get into the zone and forget one of the earliest lessons I was taught when I was learning to code:
“Commit early, commit often; Remember for every two lines of code you write you should make a commit” — a wise Instructor
When I finally did make my first real commit (and it embarrasses me to say that many commits after that) it often looked something like this:
$ git add .$ git commit -m “I added a bunch of code.”$ git push origin master
If you are unfamiliar with Git, allow me to walk you through this very quickly. In the first line we are adding all of the code we have just edited to our git staging area. In the second line we are committing/saving that staged code to our local git repository. And finally in the last line we are pushing those changes up to a repository online. This way of making a commit may be fine when you are just starting out and are still unfamiliar with the git process, but it could cause complications further down the line when you begin working on more complex projects.
It wasn’t until speaking with a more experienced developer that I was introduced to a more advanced way to create git commits, git add -p. In this article I will describe why you should be making small commits, how this command works, and how it will allow you to begin making more targeted, impactful, and granular commits, as well as build the habit of committing more frequently.
Why is it important to make small commits?
It is an industry convention that a developer should make small easily read commits, but why? There are several reasons for this. First making a small commit makes it easier for you to keep track of the changes you are making as you make them. Smaller commits also allow you to quickly make fixes if you unintentionally break your application. Furthermore, making a small commit allows other developers who may look at your source code to understand what you were doing at the time you added an update or a feature
What is “git add -patch”
git add -p is short for git add --patch and it is a git option that allows you to make more specific commits. How it works is that it will go through all new changes in your code and display hunks of them at a time for you to decide what you would like to stage or not stage.
To use this command after making some changes simply run this command:
git add -p// or git add --patch
Once you do you will be shown a message similar to this:
If we look at the bolded text we can see what file we are in that has changed from our last commit. And if we look at the green text we will see what was added to the file. If we changed any changes to already existing code, it would look something like this:
Here our old code is marked in red and the new edits are green. The last line we see here is asking us what we want to do with this hunk of code and provides us with a variety of options. Which leads to the question — what does each option mean?
To get a simple description of each option simply hit “?” and return. This text will pop up in your terminal:
For slightly more in depth description keep reading below:
y - stage this hunk - this command adds the current hunk to staging meaning it is ready.
n - do not stage this hunk - this command won’t add the current hunk to staging.
q - quit; do not stage this hunk or any of the remaining ones - this command quits out of the staging process. Any hunks before this one that has been added to staging will still be staged but the current hunk and all hunks after will be ignored.
a - stage this hunk and all later hunks in the file - this command works similar to the `git add .` call. It will stage all changes made from this hunk on.
d - do not stage this hunk or any of the later hunks in the file - this command will not stage this hunk or any hunks in the same file.
e - manually edit the current hunk- this command opens vim and allow you to edit the hunk of code in your terminal.
? - print help - this opens up the menu above.//One option not printed here is:
s - split this hunk - this option is only available if the current hunk of code has an unchanged line of code between edits. This will split the hunk into two separate hunks allowing you to stage them individually.
The commands I have found to be the most useful are ‘y’, ‘n’, ‘s’ and ‘?’. However, I have used all of them at different times. With each chunk of code, you choose to stage or not it will cycle to the next chunk of code until it cycles through all of the edits you have made or choose to quit the process.
Once you have finished the staging process you can create a much more direct commit:
Why should you use it
I recommend several reasons why you should start using this staging technique to make your commits today! First: If you happen to get into the zone when programming and forget to make commits along the way this is a great practice that will allow you to parse through your code and isolate any edits and decide what and what should not be committed in any given commit. Second: This process also allows you to give your edits another once over before committing them. Third: on a more personal note, I found that since using this commit option I have begun developing the habit of making small commits.
Conclusion
git add -p is a great git technique that will allow you to make smaller more specific commits and is a great addition to anyone’s git workflow process. Thanks for reading!
