Critical Beginner Git Usage Tips

Below are a few critical git usage guidelines/tips for beginning git users.  If one follows these guidelines, one will usually stay out of serious trouble and one can almost always recover (at least in the local git repo).  (However, once commits are pushed to a branch shared with lots of other people in a remote repo, then it is much harder to correct mistakes.)

A) Set up minimal global settings right away on every new computer!  Always set up a consistent global git user.name and user.email on every machine where you use git right away!  (Otherwise you will show up as many different developers according to git, and it is a pain to resolve these in all of the git repos you commit to after the fact).  Also, disable push of all branches by default (prior to Git 2.0) or a simple ‘git push’ will push all branches!  In addition, it is nice to see git output with color (default is no color).  And, to avoid having to resolve the same merge conflicts multiple times, turn on the git rerere feature.  To set these on a new machine, run:

$ git config --global user.name "First M. Last"
$ git config --global user.email "youremail@someurl.com"
$ git config --global color.ui true                # Use color in git output to terminal
$ git config --global push.default simple   # or 'tracking' with older versions of git
$ git config --global rerere.enabled 1          # auto resolve of same conflicts on rebase!

B) Create proper commits and commit messages:  Creating good commits with good commit messages is important for many reasons.  Commits should contain a single logical change (see “SEPARATE CHANGES” in “gitworkflows(7)” and “One Commit per Logical Change Solution” in the  Udacity git course) and commit messages should have a short summary line (under 50 chars is the target) and an optional longer body separated by a blank line (see guidelines in “How to Write a Git Commit Message”).  For example:

Summary line for changes (50 chars is target but a little longer okay)

More detailed explanatory text in the body (wrapped to about 72 chars).
The blank line separating the summary from the body is critical to make
commands like 'log --oneline', 'rebase -i', and others readable and
useful.

If you use an issue tracker, put references to them like:

Resolves: #123
Also see: #456, #789

C) Always create local commits for your changes in local branches before you run any git commands that might modify your local uncommitted changes.  The commands ‘git pull’, ‘git merge’, ‘git rebase’, or other git operations can alter (or delete) your local uncommitted changes, either in the working directory or the staging area/index.  So always create (temporary) commits for these before running any of these commands (unless you want to throw away uncommitted changes in your local repo, for example with ‘git checkout’, ‘git reset’, ‘git clean’, etc.).

D) Back up local branches every few hours of work by pushing them to some remote git repo on a remote machine in case your local machine or disk goes out.  (This is why local git branches are better than git stashes because you can back them up to other repos in a version controlled way.  You can’t do that with git stashes.)

E) You can always recover an earlier state of any of your local branches by looking at ‘git reflog‘ and then use a combination ‘git checkout‘ and/or ‘git reset –hard‘, etc. (see How to undo (almost) anything in git).

F) Never delete a local git repo (unless you are completely done with it).  Your local git repos have a wealth of information that can’t be pushed to other git repos (e.g. ‘git rerere’ info, ‘git reflog’ info, etc.).  Because of ‘E’, you should never have to delete a local git repo and re-clone to get out of some “bad” state of the local git repo.  Only a corrupted disk that corrupts the local git DB history (which is extremely rare) should cause you to have to re-clone the local git repo.  (If you feel like you need to delete your local git repo to get out of some bad state of a non-corrupted repo, you did not learn the basics of git well enough so keep learning!)

G) Don’t commit large generated (binary) files in a git repo.  These get stuck in the git history forever and can only be removed by “filtering” the git repo (which is a very disruptive process for everyone involved).

H) Never do ‘git push -f’ to a remote branch shared with other people unless everyone involved really knows what they are doing (and very few git users know how to adjust to a reset remote branch or even what that means).

I) Create local “checkpoint” commits then cleanup with ‘git rebase -i @{u}’ before pushing.  To provide for easy local “undos”, commit often locally using “checkpoint” commits (convention is to use commit summary lines starting with “WIP:”). But before pushing these commits to a remote shared branch, use ‘git rebase -i @{u}’ to clean up and reorganize the commits into good “logical” commits (see above).

There are many other helpful guidelines that one can come up with for using git but the above ones are arguably the most helpful for git beginners.