Git is the go-to tool for any developer these days. Since its birth back in 2005, it has traveled a long way; a lot of tools made good use of Git’s open-source architecture to come up with even better tools. But Git’s intuitive and easy-to-master control became its USP. Here we present the top 10 tips and tricks that are surely going to make your day even livelier.
As simple and trivial a task as renaming a directory structure can become a major pain in your neck if not done properly. There’s a well-known bug in Git’s OS X distribution that causes causing issues when the users try to rename a file or directory using Mac’s default Disk Format.
One petty solution is to use an intermediate name for the file (or directory) and then rename it to the case-changed format. But it’s not foolproof and tends to cause version mismatch. Another (and probably better) way out of this mess is to use the Disk Utility, create a new volume, and move your Git repo to this volume. Hopefully, you won’t be facing that pesky Git bug anymore.
Removing a file or directory from the current commit is pretty straight forward. Simply utilize the rm command:
git rm <filename>
or (to remove it only from the Git repo, and not from the local file system):
git rm --cached <filename>
git commit -m "remove filename"
But in order to get rid of the file completely from the history, you need to execute the following command:
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch file_path" HEAD
Point to remember here is that it might take a while to complete the whole process (in the magnitude of hours). So, be patient.
Handling large files (especially those over 0.5 GB mark) was and still is one of the toughest nuts to crack for a version control system. If you don’t keep a track of these files regularly, you run the risk of messing things up real bad. But on the other hand, if you update the repo way too frequently, you are certainly going to bloat the repo.
One solution might be to maintain the file in a separate repo. Git-submodule would be your best friend in that case. But this might not work if this file is absolutely necessary for the project. There are many tools available specifically for this job.
First comes the ‘Large File Storage’ extension for Git. By installing it locally you can have a smaller and optimized Git repo. Next is the git-annex – a tool made for keeping track of big files efficiently. By maintaining a tree of the files (using symlinks), you get an optimal repo (in fact, you might as well delete the content of the file).
The ability to roll back to an earlier version of the project is arguably the most useful part of using a version control system like Git. There are again two ways of doing this. First, using the commit hash, and second, using directly the reset command.
1. Each commit that you make has an associated hash code. To get a simplified list of the hashes to execute the following command:
git log --oneline
It should result in a list of 2-tuples consisting of the hash and the corresponding commit message. You can test any earlier version using this command:
git checkout <your_hash>
Reverting your last commit is equally easy:
git revert <unwanted_hash>
2. Now comes the second option. Say you want to restructure some earlier version from top to bottom, so git amend is not going to be of much help. Use the reset command to rewind the current HEAD to the preferred version:
git reset --soft HEAD~1
Notice the –soft option. It tells that the undone revisions should be left alone. If you want to get rid of the undone revisions as well, use the –hard flag instead. Also, note the HEAD~1 option. It tells that you are interested in reverting back to the immediate ancestor version of the current commit. You can use the ‘~’ and ‘^’ characters to effectively denote any node in the version graph.
The commit-graph presents an intuitive and easy-to-interpret view of the whole activity history. A lot of different tools and software provide this functionality (for example, GitHub and GitLab by default come with this functionality).
You can use the git log –graph command to print the commit-graph along with the commit messages. You might also be interested in the –pretty, –abbrev-commit, and –date flags to make it nicer.
The first time you try to commit to a repo, you are usually prompted to fill up your username and the mail id. Well, these are saved in your ~/.gitconfig file. But wait, there’s more to it. This file is used to store the global configuration for all your repos such as the username, aliases, default behavior of certain commands and so on.
Noticed how it’s stated in the earlier section that it is YOUR config file and not your repo’s? Yup, that’s exactly where the difference lies. Your repo-specific config file (that can be found in the .git directory) lists all the local settings specific to the parent repo. These settings override the global settings specified in the ~/.gitconfig file.
Want to know what are the things that have changed in the last few days? Use what changed the command to get a gist of the edits and additions that the project has seen. Execute the following command to see the changes made to the file ‘gitk’ in the last 4 weeks.
git whatchanged --since="4 weeks ago" \-- gitk
You can considerably reduce physical labor by using aliases. Aliases have been a popular tool for bash users for a long time. For example, the following command is going to create a shorthand alias rev for the command rev-parse –show-toplevel.
git config --global alias.rev "rev-parse --show-toplevel"
Every dev faces that situation when she resumes the work after a short break only to find out that the project is broken thanks to some newly added feature. The bisect command is going to be the savior in such cases and find out the first commit from where things went berserk.