Since the founding of Git back in 2005 by Linus Torvalds, the software industry has transformed dramatically to rely heavily upon the technology for version control to track files. Currently, nearly every programming team in the professional world is using Git, and there is really almost no serious challenger out there especially with code hosting services like Github, Bitbucket, and Gitlab causing even further adoption.
In this article, I will explain some of the commands I use every day in Git to allow me to stay productive while managing my own code. Hopefully, after this, you will be able to come away with some helpful commands and have some you even want to save!
The git reset command is used to reset the HEAD to a specific state. In this part, we will see a few ways to use it to achieve particular items.
The reset command, used with the --hard option, is a destructive operation that will rewrite your git history, so you must be extremely careful when using it. However, reset --hard can become very handy if you know what you’re doing.
To put your mind at ease, as long as you don’t push the changes to the remote server, you’re safe. Things get complicated when you rewrite the server Git history, as your unique source of truth (the server) is no longer the right source to follow.I like using reset --hard when I want to restart from another branch’s state. For instance, I typically use it when I want to rewrite a Git history of a working copy.
I reset my local branch to the state where it was initially, and then I better organize the working copy by getting the commits from the server one by one in an order that best suits.
On the other hand, the reset --soft command is less destructive, as it will rewrite the Git history, but all the changes of each commit you reset will come back to you.
reset --soft is very handy when you’ve shipped one or multiple commits, but you realize that you want to restructure the way the commits are organized, as it allows you to reset to the starting point before you committed your changes.
Enhance your git commit usage:
Amending has a secret power. You should generally use this command to edit the commit message, but it can also be used to add more changes to an already committed commit.Indeed, if you stage the changes and apply an amend, the staged changes will be added to the commit.
You can even add --no-edit if you don't want to edit the commit message.However, that operation is seen as destructive, as it could rewrite the Git history since you’re adding changes to an already committed commit. So, you can only push it by using the --force option. Be careful when using it!
A small note on the --force option: I tend to use --force-with-lease more often, as it will protect you against a potential situation wherein someone pushes a commit while you rebase. It could save lives, as it won’t push and erase the commit that a co-worker pushed just before you.
Reapply a commit on top of another base:
Rebasing permits you to apply a commit on top of an existing commit, but it doesn't create an additional merge commit as git merge does. That command is usually used to keep your branch feature up-to-date with the main/master branch.
It applies all the missing commits from main/master to your branch.
Enhance your rebasing by going interactive:
Interactive rebasing will give you more granularity and more power over how you want to organize your commit history. It's a convenient and powerful tool, but it can also be a source of confusion, as the commands are complex to assimilate.
Git will enter interactive mode to let you rebase interactively.
For instance, we want to update the last ten commits’ history in this real-world example.
Git provides a range of commands that will help us rewrite the history to our will:
If you want to run it, you have to transform the pick command into an edit command. Then you can save the file, and Git will open a new editor to let you update the commit you wanted to update.
Small tip: You can use the first letter of the command. In our case, it would be e.
The fixup command is convenient when you want to merge multiple commits into one.
For instance, if you created many commits while you were developing, but in the end, you realized that you could merge your commits to form a single commit, the fixup command can help you with that.In the example I gave above, we will make one single commit out of the commit f9c4640c8d and the previous commit 1c4d338cc2, and the commit message will be the one of those mentioned above. You can use this command multiple times at once.
The squash command is almost the same as the fixup command explained above, except that squash keeps the commit message of the squashed commit and inserts it into the previous commit.
Applying the changes introduced by existing commits:
For me, cherry-picking is the Git symbol of flexibility.
It allows you to pick a commit from a branch and apply it in your current branch.
You can also pick a range of commits to apply in your current branch:
Tip: the minor ^ character includes a commit in the current commit. Otherwise, the shaCommitOldest would be excluded.
To give a real-world example, I usually heavily rely on this Git command when I want to completely rewrite the Git history of my feature. I use a reset --hard, which puts me up to date with master/main, and then I reapply the commits that I want from the server.
Applying changes from specific branches/commits on specific files
Ever wanted to reset a file's state from an existing commit?
With the command above, you can retrieve the state of a file from a specific commit or branch and apply it to your current working branch.
Adding new origins from forked repositories
Have you ever forked a repository to submit a pull request and, a few days later, ended up out of sync with the original repository?
If you’ve ever encountered that situation, you may have already run the command above. It permits you to add the original repository to your forked repository to be able to pull the changes out of the original repository. Once you run the above command, you can perform a git pull to pull the changes from your forked to the original repo you just added. Tip: You can replace the original keyword with whatever name allows you to identify the source better. However, take care not to erase an existing source.
Store the changes in a dirty working directory.
The stash command is convenient when you want to save some changes you made but want to jump to another branch without committing. For instance, if you try to create a change on the feature branch you are working on and then try to change branches, an error message will appear to tell you that you must have a clean working directory before switching. You then have two solutions: committing or stashing.
By using stash, Git will keep your changes, and as soon as you need them, you can re-invoke those changes by using:
Productivity at a glance.
Go back to the previous branch
Do you know what cd - is doing? It permits you to go back to the previous path you were on.You can use the same mechanism as switching branches to return to a the branch you were previously on.
Git is a tool you will use almost every day during your career as a software engineer. You will type the same commands thousands and thousands of times. What if, instead of writing the full command each time, you wrote a couple of letters to gain time and productivity?
Git thought of that by introducing Git aliases:
Do not hesitate to create new aliases for other commands you type a lot.
For many, the learning curve for Git is pretty steep, but with a few go-to commands, you should be able to cover most operations you would like to perform in Git. One downside many point to when working with Git is that there is no graphic interface since it is CLI based, but if you are in the camp of people who want a more visual tool, be sure to check out GitKraken to get a more visual interface to interact with Git.
A big part of becoming more comfortable with Git involves time and practice, but two resources in particular helped me improve faster:
Be sure to check them out if you are trying to level up your knowledge as well; I can guarantee it will be worth your time.
With that, I hope you came way with some helpful Git tips and excited for you all to join me for my next blog article!
A Smarter Way to Use Git
The connection Pieces has built with Git has made engineers more productive than ever. With Pieces, developers are able to save their most useful Git commands in their own micro-repository and easily access them through a variety of integrations including the Pieces CLI. Within seconds, developers can search for frequently used Git code snippets using tags, share their favorite Git commands with others using shareable links, and even save documentation on a certain command using related links in Pieces for Developers.