Take control of your commits with git add’s patch mode
This is one of the most powerful features of git that can really improve your workflow and will help you take one more step towards being a super awesome developer.
Here are a few benefits of adding files using patch flag
- Take control of what you push.
- More effective modular commits, only push the functionality you want.
- Fewer conflicts while working with multiple developers on the same file.
- Easy to have different lines of code for different environments (for eg. if you have different credentials).
And much more, the more you explore it, the more benefits you will find.
Usage
You can use the patch mode by adding -p or --patch after git add while adding the files for commit.
git add -p myFile.js
or
git add --patch myFile.js
After you run this command, git will prompt you with small pieces of the file, where you have made changes, asking you to perform the following actions. It represents every edited chunk or portion of the code as hunk.
y — stage this hunk
n — do not stage this hunk
q — quit; do not stage this hunk or any of the remaining ones
a — stage this hunk and all later hunks in the file
d — do not stage this hunk or any of the later hunks in the file
g — select a hunk to go to
/ — search for a hunk matching the given regex
j — leave this hunk undecided, see next undecided hunk
J — leave this hunk undecided, see next hunk
k — leave this hunk undecided, see previous undecided hunk
K — leave this hunk undecided, see previous hunk
s — split the current hunk into smaller hunks
e — manually edit the current hunk
? — print help
All of the above mentioned options are pretty simple to understand and implement except e, manually editing the hunk. This could be a bit tricky, so let’s try and understand this.
Why do we need to edit the hunk manually?
We will be using this, when git is not able to break down the hunk as we want it to. Consider the hunk in the above screenshot, this hunk cannot be further broken into smaller hunks, but I don’t want to commit the console.log statement. So let’s go ahead and try the edit mode on the above piece of code to understand how it works.
So here I am in the edit mode, there are 2 values which are really important to understand.
Point 1. -2,6 is the existing state of the file
Here 2 means the representation of the hunk is starting at line number 2 in your file, let’s see how our index.js files looks like.
It does start with line number 2 and if you count the lines without the + they are 6. So the number 6 is representing the number of lines in the hunk without the updates (Don’t count the lines starting with # they are just git instructions).
Point 2. +2,13 is the updated state of the file
Here 2 again means that the hunt starts from line 2 and 13 is the total number of lines after the code update we have made.
Ok! all clear so far? So let’s update the file and remove the line with console.log statement.
So once I remove the line I also need to update the value above from 13 to 12 as our new hunk now has only 12. Now save changes and you have added the edited hunk of code to git.
Now run the command git diff --cached to confirm that editing the hunk worked fine and the screenshot below shows it did (😎 AWESOME!).
It was that easy! Keep trying it out and don’t worry if it doesn’t work the first time. Editing is a little confusing but fun when you completely understand it. Hope this helps your workflow, feel free to ask questions in the comments.
