How to tidy up the history of your commits in Git

Publish a translation articleswe found on hackernoon.com. Its author, Thiago Miranda, writes on how to make working with Git more convenient and efficient.

About some extremely useful commands in Git

For the last month I have been doing pair programming and have created several hundred commits in Git. In the article, I will share the most important of what I learned during this time: I will talk about working with the history of commits, about successful techniques and how to implement them with a dozen teams.

1. What is the story in Git?

An accurate register of all commits containing changes made to files. In it, you can track specific changes and the time they were made, or compare the current version with the previous one. Where to see the story? Enter the command through Git Bash:

git log --oneline

If you have too many commits, you can switch from one comment to another using the arrow keys or the Page Up / Page Down keys – just like in any other file. To exit, press the hot key (q).

2. About comments on commits

Do not write meaningless comments, they should be concise and not requiring explanation. Their task is to indicate what changes you have made to the code and what they affect.

  • How not to: “Fixed index.html”
  • As it should: “Improved the speed of the navigation bar”

Let’s see what this is for.
Imagine that you are working on such a large-scale project that most of the specialists employed in it do not even know. You develop a new feature, test it on your equipment, and everything works fine.

But after a push everything suddenly stops working, and the first thing you check is the changes made during the development of this feature. In the Git log, you find a lot of commits with comments in the “fixed” style. Imagine how much time you have to spend on finding the right one!

3. Always make commits

Commits, commits, and again commits. Finished the function – add a commit, improved the style of a block element – add a commit and so on. Ideally, you should send a commit with every change.

Perhaps you are thinking: why are there so many commits? The main reason is that your new functionality may conflict with someone else’s code, but if you always commit small changes, finding and fixing them will be easier. This saves you time by tracking dozens or hundreds of lines modified in the same commit.

4. Correct the last commit comment

What if, after adding a small commit to your local repository, you want to correct the typo or make a comment on the commit in more detail? Making changes is fairly simple with the command:

git commit -m “correct message” --amend

Please note: if you have already started committing to a remote repository, this command is better not to use.

See details in official documentation.

5. Combine the last X commits into one

Situation: sending a commit to a new feature, you understand that you need one more small change, make minimal changes and commit again … As a result, 5 commits are about the same thing. It happened? Such commits are knocked out of the general view of your story in Git, but if you want, they can be easily fixed using the command:

git reset HEAD~3

The HEAD ~ 3 command rolls back 3 top commits, including the most recent one. In this example, your last three commits will be deleted from the log, but the changes in the code will remain in place. Now it’s time to see what code you need to commit, for this we enter the command:

git stage --diff

You will see that all the changes to the commits that you removed from the history are now indexed, so you can commit them again, this time in one go.

Note that HEAD usually refers to the last commit you added. If you are not sure, check the Git log. If your last commit was frozen (not the most common case), the HEAD ~ 1 command will erase all the commits from the frozen branch. To learn more, see the documentation.

6. Delete the last commit with changes

Be careful, as this method will erase all changes without the ability to roll back. It is usually used after experimenting with code if their result does not meet expectations. I recommend that you first try in the sandbox repository.

git reset –-hard HEAD~1

Now your last commit has been deleted, as well as all the relevant changes in the code.

7. Clear your commit history

The most efficient way to clear the commit history is to use the rebase command. Be careful: you can delete a commit by accidentally pressing the wrong key. So, let’s run rebase interactively (-i flag) with the command:

git rebase -i HEAD~5

As soon as you enter it, you will see a list of the last 5 commits (HEAD ~ 5) inside the terminal. All commits are sorted by date, i.e. the newest one at the top (this list is opened using Vim, the default Git text editor that allows editing text files inside the terminal). And here is a brief instruction with several useful commands. In most cases, you will need the squash and reword commands.

Replacing the pick command with squash will remove this commit from the log, and all changes to the code will be grouped with the last commit highlighted by the pick command.

If you want to adjust the comment, you can replace the pick command with the reword command and rewrite the comment.

Now you can go to the next window, where you need to write one comment for the group of commits that you are going to glue using squash. To continue, press ESC and enter:

:wq!

Colon (:) necessary to show that you want to pass a command, (w) – to record (save) changes, (q) – to go out, and (!) – to execute a command.

Please note that each commit group will receive your comment. The result can be checked in the Git log.

If for some reason you leave this window without completing the operation, you can return at any time with the command:

git rebase --edit

If you want to leave the window without saving the changes, press the ESC key and enter:

:q!

Vim will receive a command to close the file without saving.

8. Manage indexing

Usually, you should send commits to a single file or to a group of related files. But how then to quickly make changes during indexing?

Let’s say you have 3 files, and only 2 of them need to be committed. In this case, you can try the following command:

git add .

Now remove the file that you do not need from indexing:

git reset -- Readme.txt

And check the result:

git status

Add all files from some extension, for example CSS:

git add *.css

Added everything by mistake? Then clear the index using the command:

git reset --

If you need more complex operations, you can add files to the index using the dialog mode:

git add -i

First, select an option by entering the appropriate number, for example (3), to roll back your actions.

By selecting an option, you can enter a list of files that you want to remove from indexing, one after another.

When done, press (Enter).

Files are added in the same way. Using option (4) add an untracked file.

To exit, enter (q) in the options menu.

9. Conclusion

The main thing to do before pushing to a remote repository, and especially before merging your branch, is to make sure that you tidy up the commit history. Once you push everything into a remote repository, nothing can be fixed.

Want to learn more about pair programming and get started remotely? Take a look at Microverse.org.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *