These helpful tips will change the way you work with the popular version control system.
Git is one of the most common version control systems available, and it’s used on private systems and publicly hosted websites for all kinds of development work. Regardless of how proficient with Git I become, it seems there are always features left to discover. Here are seven tricks that have changed the way I work with Git.
1. Autocorrection in Git
We all make typos sometimes, but if you have Git’s auto-correct feature enabled, you can let Git automatically fix a mistyped subcommand.
Suppose you want to check the status with git status but you type git stats by accident. Under normal circumstances, Git tells you that 'stats' is not a valid command:
$ git stats
git: ‘stats’ is not a git command. See ‘git --help’.
The most similar command is status
To avoid similar scenarios, enable Git autocorrection in your Git configuration:
$ git config --global help.autocorrect 1
If you want this to apply only to your current repository, omit the --global option.
This command enables the autocorrection feature. An in-depth tutorial is available at GitDocs, but trying the same errant command as above gives you a good idea of what this configuration does:
$ git stats
git: ‘stats’ is not a git command. See ‘git --help’.
On branch master
Your branch is up to date with ‘origin/master’. nothing to commit, working tree clean
Instead of suggesting an alternative subcommand, Git now just runs the top suggestion, which in this case was git status.
2. Count your commits
There are many reasons you might need to count your commits. Many developers count the number of commits to judge when to increment the build number, for instance, or just to get a feel for how the project is progressing.
To count your commits is really easy and straightforward; here is the Git command:
$ git rev-list --count
In the above command, the branch-name should be a valid branch name in your current repository.
$ git rev-list –count master
32
$ git rev-list –count dev
34
3. Optimize your repo
Your code repository is valuable not only for you but also for your organization. You can keep your repository clean and up to date with a few simple practices. One of the best practices is to use the .gitignore file. By using this file, you are telling Git not to store many unwanted files like binaries, temporary files, and so on.
To optimize your repository further, you can use Git garbage collection.
$ git gc --prune=now --aggressive
This command helps when you or your team heavily use pull or push commands.
This command is an internal utility that cleans up unreachable or “orphaned” Git objects in your repository.
4. Take a backup of untracked files
Most of the time, it’s safe to delete all the untracked files. But many times, there is a situation wherein you want to delete, but also to create a backup of your untracked files just in case you need them later.
Git, along with some Bash command piping, makes it easy to create a zip archive for your untracked files.
$ git ls-files --others --exclude-standard -z |\
xargs -0 tar rvf ~/backup-untracked.zip
The above command makes an archive (and excludes files listed in .gitignore) with the name backup-untracked.zip
5. Know your .git folder
Every repository has a .git folder. It is a special hidden folder.
$ ls -a
. … .git
Git mainly works with two things:
The working tree (the state of files in your current checkout)
The path of your Git repository (specifically, the location of the .git folder, which contains the versioning information)
This folder stores all references and other important details like configurations, repository data, the state of HEAD, logs, and much more.
If you delete this folder, the current state of your source code is not deleted, but your remote information, such as your project history, is. Deleting this folder means your project (at least, the local copy) isn’t under version control anymore. It means you cannot track your changes; you cannot pull or push from a remote.
Generally, there’s not much you need to do or should do, in your .git folder. It’s managed by Git and is considered mostly off-limits. However, there are some interesting artifacts in this directory, including the current state of HEAD:
$ cat .git/HEAD
ref: refs/heads/master
It also contains, potentially, a description of your repository:
$ cat .git/description
This is an unnamed repository; edit this file ‘description’ to name the repository.
6. View a file of another branch
Sometimes you want to view the content of the file from another branch. It’s possible with a simple Git command, and without actually switching your branch.
Suppose you have a file called README.md, and it’s in the main branch. You’re working on a branch called dev.
With the following Git command, you can do it from the terminal.
$ git show main:README.md
Once you execute this command, you can view the content of the file in your terminal.
7. Search in Git
You can search in Git like a pro with one simple command. Better still, you can search in Git even if you aren’t sure which commit — or even branch — you made your changes.
$ git rev-list --all | xargs git grep -F ‘’
For example, suppose you want to search for the string “font-size: 52 px;” in your repository:
$ git rev-list –all | xargs git grep -F ‘font-size: 52 px;’
F3022…9e12:HtmlTemplate/style.css: font-size: 52 px;
E9211…8244:RR.Web/Content/style/style.css: font-size: 52 px;
Top comments (8)
These are solid. Even I learned something new and useful, and I thought I was too advanced.
I agree <3, by the way can you re-write the command here and explain it to me in details, thanks! :)
I would add a very useful one to this list git-scm.com/docs/git-reflog
Very useful when you rewriting your history (rebase...) and it helps reshow previous “deleted” commits that were sometimes deleted by mistake, based on your local history.
It has saved me an amount of work in some specific situations, but indeed a good one to know too.
Nice Article ! Although point 1 autocorrect has been super helpful for me (thank you), point 2 counting the commits in a particular branch doesn't work to me [I tried to count commits in a particular branch which was a child branch of some other branch but showing the entire commit counts of the repository]
The correct command is: git rev-list --count
In the article, there's just one hyphen instead of two before the count. Probably a typo.
Great article, loved it :)
Not talking about the typo dude, Even I used two hyphens only. It will show the count, no doubt !
My point is that --
Lets say branch 'b' (child branch) which is taken from branch 'a' (parent branch), when i try to count the commits made only in branch 'b' - it will list the total commits including i did in the branch 'a'. (it will display total commits made in the repo or at least from its parent tree - will not show that accurate count on that particular child branch)
Great information loved your content, I have also started writing post about Opensource, Github, Android dev, Webdev, IoT, Cloud etc.
you can check it out here
Codewithgauri
Thanks :)
wow, I use git every day, but you teached me 4 of the seven, thanks