Tips and Tricks¶
Git can do a lot more things than we have seen during this training. This section will cover some of the more interesting things you can do with git.
git grep
¶
The git grep command is useful for searching through all of the files that are under revision control. Files that are not under revision control are ignored.
References:
git add -i
¶
The git add -i command makes the git add command interactive. You can select which files to add, update or patch. It is quite powerful and well worth learning how to use.
I also find git add -p to be quite useful.
For more information:
$ git help add
gitk
¶
The gitk tool provides a graphic display of the history of the repository. To use gitk, you may need to install the gitk package (using apt-get, yum or whatever your system uses to manage packages).
gitk shows a very dense view of the history of the repository by showing the following:
Branches (local and remote).
Which commit is currently checked out.
Tags (and associated meta data).
Commit relationships.
Commit meta data.
To view the history for all branches at once:
$ gitk --all
Sometimes it is useful to pull down changes from a remote, but review them before merging locally:
$ git checkout master
$ git fetch origin
$ gitk origin/master
$ git merge origin/master
Another useful operation is to view the history of a specific file or directory:
$ gitk -- path/to/file
$ gitk -- path/to/directory
Right clicking on the subject line of a commit in gitk will bring a context menu that will allow you to before some basic git operations.
I often leave gitk running in the background as I work through changes and
then use the File->Reload
menu option to refresh the view of the
repository.
Using gitk as part of this workflow can greatly improve the quality of your commits and make your fellow developers lives easier as you will be able to find and fix bad commits before you push them to other:
$ git checkout -b feature/cool-stuff master
$ vim <files> # do some work
$ git status # see what you changed
$ git diff # review your work
$ git diff --check # Check for white space errors in your changes
$ gitk # review you work WRT to history
$ git add <files> # stage your changes
$ gitk # more review WRT to history
$ git ci # commit locally
Iterate on the above to generate a series of commits and get ready to push:
$ gitk # Review the patchset you have generated locally
$ git rebase -i <ref> # Cleanup your ugly or embarressing commits
$ gitk # More review (are you starting to see pattern developing?)
$ git push origin feature/cool-stuff # publish your changes to the world for peer-review
Now, you may be asking yourself, that seems like a lot of extra work? Yes, it is, but asking for peer-review of your code for things that you should have fixed before pushing is extra work for you and the reviewer later. And then if the review misses a bug that manifests a year later, how much extra work will it be to fix that bug then?
git diff --check
¶
You can have git check for white space errors in your changes before you commit them with the git diff --check or git diff --cached --check. You should strive to use these commands before every commit.
Many Open Source project maintainers get grumpy if merge requests contain white space issues.
git describe
¶
Todo
Discuss git describe
and how it can be used to automate versioning.
Showing the Git Branch in your Prompt¶
If you are using bash as your shell, you can modify the command
prompt using the PS1
environment variable. If you install git and
bash_completion, you will have a
/etc/bash_completion.d/git-prompt
file installed on your system. The
git-prompt
script should get sourced by your shell at login and will
provide a __git_ps1 shell function.
Using the __git_ps1 shell function in your PS1
variable will
show the currently checked out branch in your prompt.
Here’s what my prompt looks like (except for colorization):
### [11:35:29 am][Ubuntu-16.04] Branch: master
### [troth@example:~/git/git-train/git-training/source]
>--> $
And here’s the code from my ~/.bash_profile
to generate that prompt:
OS_REL=$(lsb_release -irs | tr '\n' ' ' | tr ' ' '-' | sed -e 's/-$//')
export OS_REL
_BLK_ ()
{
printf -- "\033[0m"
}
_RED_ ()
{
printf -- "\033[31m"
}
_GRN_ ()
{
printf -- "\033[32m"
}
_BLU_ ()
{
printf -- "\033[34m"
}
_CYN_ ()
{
printf -- "\033[36m"
}
PS1='\n$(_GRN_)### $(_BLU_)[\T \D{%P}]$(_CYN_)[${OS_REL}]'\
'$(__git_ps1 "$(_RED_) Branch: %s")\n'\
'$(_GRN_)### [\u@\h:\w]$(_BLK_)\n>--> \$ '
export PS1
Showing the currently checked out branch in the prompt saves you from
constantly having to run git branch
to see which branch you are working on.
Writing Good Commit Messages¶
Writing a good commit message is an art and takes practice, but is crucial to the sanity of future developers looking at your commit (your future self included).
The following is probably one of the best articles on writing git commit messages:
Crafting a Good Commit¶
Todo
Discuss what makes a good commit and/or commit series.