17 Best Git Tips For Developers

This article is aimed at somebody who has been using git for three months or more.

I’ve been using git for a few years, and I wanted to share the most practical tips that I’ve learned along the way. Hopefully, it will be useful to somebody out there.

This article is aimed at somebody who has been using git for three months or more.

Table of Contents:

1. Parameters for better logging
   git log --oneline --graph
2. Log actual changes in a file
   git log -p filename
3. Only Log changes for some specific lines in a file
   git log -L 1,1:some-file.txt
4. Log changes not yet merged to the parent branch
   git log --no-merges master..
5. Extract a file from another branch
   git show some-branch:some-file.js
6. Remember the branch structure after a local merge
   git merge --no-ff
7. Fix your previous commit, instead of making a new commit
   git commit --amend
8. Three stages in git, and how to move between them
   git reset --hard HEAD and git status -s
9. Revert a commit, softly
   git revert -n
10. Ignore the white space
    git diff -w
11. Only “add” some changes from a file
    git add -p
12. Discover and zap those old branches
    git branch -a
13. Stash only some files
    git stash -p
14. Good commit messages
15. Git Auto-completion
16. Create aliases for your most frequently used commands
17. Quickly find a commit that broke your feature (EXTRA AWESOME)
    git bisect

1. Parameters for better logging

Sample Command git log --oneline --graph

Chances are, by now you’ve used git log. It supports a number of command-line parameters, which are very powerful, especially when used in combination. Here are the ones that I use the most:

• --author=“Davisonpro" – Only show commits made by a certain author
• --name-only – Only show names of files that changed
• --oneline – Show commit data compressed to one line
• --graph – Show dependency tree for all commits
• --reverse – Show commits in reverse order (Oldest commit first)
• --after – Show all commits that happened after certain date
• --before – Show all commits that happened before certain data

For example, I once had a manager who required weekly reports submitted each Friday. So every Friday I would just run: git log --author="Davisonpro" --after="1 week ago" --oneline, edit it a little and send it into the manager for review.

Git has a lot more command line parameters that are handy. Just run man git-log and see what it can do for you.

If everything else fails, git has a --pretty parameter that lets you create a highly customizable output.

2. Log actual changes in a file

Sample Command git log -p filename

git log -p or git log -p filename lets you view not only the commit message, author, and date, but actual changes that took place in each commit.

Then you can use the regular less search command of “slash” followed by your search term/{{your-search-here}} to look for changes to a particular keyword over time. (Use lower case n to go to the next result, and upper case N to go to the previous result).

3. Only Log changes for some specific lines in a file

git log -L 1,1:some-file.txt

You can use git blame filename to find the person responsible for every line of the file.

git blame is a great tool, but sometimes it does not provide enough information.

An alternative is provided by git log with a -L flag. This flag allows you to specify particular lines in a file that you are interested in. Then Git would only log changes relevant to those lines. It’s kind of like git log -p with focus.

git log -L 1,1:some-file.txt

4. Log changes not yet merged to the parent branch

Sample: git log --no-merges master..

If you ever worked on long-lived branches, with multiple people working on it, chances are you’ve experienced numerous merges of the parent branch(i.e. master) into your feature branch. This makes it hard to see the changes that took place on the master branch vs. the changes that have been committed on the feature branch and which have yet to be merged.

git log --no-merges master.. will solve the issue. Note the --no-merges flag indicates to only show changes that have not been merged yet to ANY branch, and the master.. option, indicates to only show changes that have not been merged to the master branch. (You must include the .. after master).

You can also do git show --no-merges master.. or git log -p --no-merges master.. (output is identical) to see actual file changes that are yet to be merged.

5. Extract a file from another branch

Sample: git show some-branch:some-file.js

Sometimes it is nice to take a pick at an entire file on a different branch, without switching to this branch.

You can do so via git show some-branch-name:some-file-name.js, which would show the file in your terminal.

You can also redirect the output to a temporary file, so you can perhaps open it up in a side by side view in your editor of choice.

git show some-branch-name:some-file-name.js > deleteme.js

Note: If all you want to see is a diff between two files, you can simple run:
git diff some-branch some-filename.js

6. Remember the branch structure after a local merge

Sample: git merge --no-ff

I like to create a new branch for every new bug or feature. Among other benefits, it helps me to get great clarity on how a series of commits may relate to a particular task. If you ever merged a pull request on GitHub or a similar tool, you will, in fact, be able to nicely see the merged branch history in git log --oneline --graph view.

If you ever try to merge a local branch, into another local branch, you may notice git has flattened out the branch, making it show up as a straight line in the git history.

If you want to force git to keep branches history, similarly to what you would see during a pull request, you can add a --no-ff flag, resulting in a nice commit history tree.

git merge --no-ff some-branch-name

7. Fix your previous commit, instead of making a new commit

Sample git commit --amend

This one is pretty straightforward.

Let say you made a commit and then realized you made a typo. You could make a new commit with a “descriptive” message typo. But there is a better way.

If you haven’t pushed to the remote branch yet, you can simply do the following:

1. Fix your typo
2. Stage the newly fixed file via git add some-fixed-file.js
3. Run git commit --amend which would add the most recent changes to your latest commit. It will also give you a chance to edit the commit message.
4. Push the clean branch to remote, when ready

If you are working on your own branch, you can fix commits even after you have pushed, you would just have to do a git push -f (-f stands for force), which would over-ride the history. But you WOULD NOT want to do this on a branch that is being used by other people (as discussed in the rebase section above). At that point, a “typo” commit, might be your best bet.

8. Three stages in git, and how to move between them

Sample git reset --hard HEAD and git status -s

As you may already know by now, a file in git can be in 3 stages:
1. Not staged for commit
2. Staged for commit
3. Committed

You can see a long description of the files and state they are in by running git status. You move a file from “not staged for commit” stage to “staged for commit” stage, by running git add filename.js or git add . to add all files at once.

Another view that makes it much easier to visualize the stages is invoked via git status -swhere -s stand for short (I think). For more visit this link http://archaeogeek.github.io/foss4gukdontbeafraid/git/stages.html

Obviously, git status will not show files that have already been committed, you can use git log to see those instead

There are a couple of options available to you to move the files to a different stage.

Resetting the files

There are 3 types of reset available in git. A reset allows you to return to a particular version in git history.

1. git reset --hard {{some-commit-hash}} – Return to a particular point in history. All changes made after this commit are discarded.
2. git reset {{some-commit-hash}} – Return to a particular point in history. All changes made after this commit are moved “not yet staged for commit” stage. Meaning you would have to run git add . and git commit to add them back in.
3. git reset --soft {{some-commit-hash}} – Return to a particular point in history. All changes made after this commit are moved to “staged for commit” stage. Meaning you only need to run git commit to add them back in.

This may appear as useless information at first, but it is actually very handy when you are trying to move through different versions of the file.

Common use cases that I find myself using the reset are bellow:

1. I want to forget all the changes I’ve made, clean start — git reset --hard HEAD (Most common)
2. I want to edit, re-stage and re-commit files in some different order — git reset {{some-start-point-hash}}
3. I just want to re commit past 3 commits, as one big commit — git reset --soft {{some-start-point-hash}}

Check out some files

If you simply want to forget some local changes for some files, but at the same time want to keep changes made in other files, it is much easier to check out committed versions of the files that you want to forget, via:
git checkout forget-my-changes.js

It’s like running git reset --hard but only on some of the files.

As mentioned before you can also check out a different version of a file from another branch or commit.

git checkout some-branch-name file-name.js and
git checkout {{some-commit-hash}} file-name.js

You’ll notice that the checked-out files will be in a “staged for commit” stage. To move them back to “un-staged for commit” stage, you would have to do a git reset HEAD file-name.js. You can run git checkout file-name.jsagain, to return the file to its original state.

Note, that running git reset --hard HEAD file-name.js does not work. In general, moving through various stages in git is a bit confusing and the pattern is not always clear, which I hoped is to remedy a bit with this section.

9. Revert a commit, softly

Sample git revert -n

This one is handy if you want to undo a previous commit or two, look at the changes, and see which ones might have caused a problem.

Regular git revert will automatically re-commit reverted files, prompting you to write a new commit message. The -n flag tells git to take it easy on committing for now, since all we want to do is look.

10. Ignore the white space

Sample git diff -w or git blame -w

Have you ever re-indented or re-formatted a file, only to realize that now git blame shows that you are responsible for everything in that file?

Turns out, git is smart enough to know the difference. You can invoke a lot of the commands (i.e. git diff, git blame) with a -w flag and git will ignore the white space changes.

11. Only “add” some changes from a file

Sample git add -p

Somebody at git must really like the -p flag, because it always comes with some handy functionality.

In case of git add, it allows you to interactive select exactly what you want to be committed. That way you can logically organize your commits in an easy to read manner.

12. Discover and zap those old branches

Sample git branch -a

It is common for a large number of remote branches to just hang around, some even after they have been merged into the master branch. If you are a neat freak (at least when it comes to code) like me, chances are they will irritate you a little.

You can see all of the remote branches by running git branch with the -a flag (show all branches) and the --merged flag would only show branches that are fully merged into the master branch.

You might want to run git fetch -p (fetch and purge old data) first, to make sure your data is up to date.

If you want to get really fancy, you can get a list of all the remote branches, and the list of last commits made on those branches by running:
git for-each-ref --sort=committerdate --format='%(refname:short) * %(authorname) * %(committerdate:relative)' refs/remotes/ | column -t -s '*'.

Unfortunately, there is no easy way (that I know of) to only show merged branches. So you might have to just compare the two outputs or write a script to do it for you.

13. Stash only some files

Sample git stash —keep-index or git stash -p

If you don’t yet know what git stash does, it simply puts all your unsaved changes on a “git stack” of sorts. Then at a later time you can do git stash pop and your changes will be re-applied. You can also do git stash list to see all your stashed changes. Take a look at man git-stash for more options.

One limitation of regular git stash is that it will stash all of the files at once. And sometimes it is handy to only stash some of the file, and keep the rest in your working tree.

Remember the magic -p command? Well it’s really handy with git stash as well. As you may have probably guessed by now, it will ask you to see which chunks of changes you want to be stashed.

Make sure to hit ? while you at it to see all available options.

Another handy trick, for stashing only some of the files, is to:

1. add the files that you DO NOT want to get stashed (i.e. git add file1.js, file2.js)
2. Call git stash --keep-index. It will only stash files that have not been added.
3. Call git reset to un-stage the added files and continue your work.

14. Good commit messages

A little while ago I came across a great article on how to write a good commit message. Check it out here: How to Write a Git Commit Message

One rule that really stood out for me is, “every good commit should be able to complete the following sentence”

When applied, this commit will: {{ YOUR COMMIT MESSAGE}}

For example:
– When applied this commit will Update README file
– When applied this commit will Add validation for GET /user/:id API call
– When applied this commit will Revert commit 12345

15. Git Auto-completion

Git packages for some operating systems (i.e. Ubuntu) come with git auto-completion enabled by default. If your operating system did not come with one(Mac doesn’t), you can easily enable it by following these guidelines:

https://git-scm.com/book/en/v1/Git-Basics-Tips-and-Tricks#Auto-Completion

16. Create aliases for your most frequently used commands

TLDR; Use git or bash aliases for most commonly used long git commands

The best way to use Git is via command line, and the best way to learn the command line is by doing everything the hard way first (typing everything out).

After a while, however, it might be a good idea to track down your most-used commands and create easier aliases for them.

Git comes with built-in aliases, for example, you can run the following command once:

git config --global alias.l "log --oneline --graph"

Which would create a new git alias named l, that would allow you to run:
git l instead of git log --oneline --graph.

Note that you can also append other parameters after the alias (i.e. git l --author="Davison").

Another alternative is good old Bash alias.

For example, I have the following entry in my .bashrc file.

alias gil=”git log --oneline --graph”, allowing me to use gil instead of the long command, which is even 2 characters shorter than having to type git l :).

17. Quickly find a commit that broke your feature (EXTRA AWESOME)

Sample: git bisect

git bisect uses the divide and conquer algorithm to find a broken commit among a large number of commits.

Imagine yourself coming back to work after a week-long vacation. You pull the latest version of the project only to find out that a feature that you worked on right before you left is now broken.

You check the last commit that you’ve made before you left, and the feature appears to work there. However, there have been over a hundred of other commits made after you left for your trip, and you have no idea which of those commits broke your feature.

At this point, you would probably try to find the bug that broke your feature and use git blame on the breaking changes to find the person to go yell at.

If the bug is hard to find, however, you could try to navigate your way through the commit history, in an attempt to pinpoint where the things went bad.

The second approach is exactly where git bisect is so handy. It will allow you to find the breaking change in the fastest time possible.

So what does git bisect do?

After you specify any known bad commit and any known good commit, git bisect will split the in-between commits in half, and check out a new (nameless) branch in the middle commit to let you check if your future is broken at that point in time.

Let say the middle commit still works. You would then let git know that via git bisect good command. Then you only have half of the commits left to test.

Git would then split the remaining commits in half and into a new branch(again), letting you test the feature again.

git bisect will continue to narrow down your commits in a similar manner, until the first bad commit is found.

Since you divide the number of commits by half on every iteration, you are able to find your bad commits in log(n) time (which is simply a “big O” speak for very fast).

The actual commands you need to run to execute the full git bisect flow are:

1. git bisect start – let git know to start bisecting.
2. git bisect good {{some-commit-hash}} – let git know about a known good commit (i.e. last commit that you made before the vacation).
3. git bisect bad {{some-commit-hash}} – let git know about a known bad commit (i.e. the HEAD of the master branch). git bisect bad HEAD(HEAD just means the last commit).
4. At this point, git would check out a middle commit, and let you know to run your tests.
5. git bisect bad – let git know that the feature does not work in currently checked out commit.
6. git bisect good – let git know that the feature does work in currently checked out commit.
7. When the first bad commit is found, git would let you know. At this point git bisect is done.
8. git bisect reset – returns you to the initial starting point of git bisectprocess, (i.e. the HEAD of the master branch).
9. git bisect log – log the last git bisect that completed successfully.

You can also automate the process by providing git bisect with a script. You can read more here: http://git-scm.com/docs/git-bisect#_bisect_run

Final Note

Git is very complicated, as you can’t learn all its concepts by just using it. Try these basic Git commands for yourself and you’ll see that the devil isn’t as black as he’s painted.