• Git Tips and Tricks
  • Overview.

    This page gives some helpful hints and tricks on using git, along with a suggested work-flow, with an explanation of its motivation and details.

    Some pertinent Git details.

    It is assumed at this point that you have a passing familiarity with CVS and/or Subversion; and that you have at least obtained a local copy (cloned) of a remote repository.

    Git (very) basics.

    Getting help.

    Glossary.

    Initializing a repository.

    git clone <repository-spec> <local-dir>

    or

    mkdir <local-dir>
       cd <local-dir>
       git init
    or (FNAL Redmine-specific)
    rclone [-r <repo>] <project> <local-name>
    where rclone is defined in cet-chg:export:unix-admin/profile.d/rclone.sh

    Basic log information.

    git log [<tree-ish>]

    Working in your local repository.

    Basic interaction with local branches.

    Basic interaction with a remote branch.

    Assuming you created your local repository with git clone, there is already one configured remote origin and you will have a local branch for each remote branch that existed at the time of your last pull or clone.

    Some more advanced operations.

    Stashing.

    This is a good way quickly to get a clean tree if you want to merge or rebase (see below) to import changes from a branch without having to commit your current work.

    Rebasing.

    Rebasing is changing history, if you think that git stores history. As mentioned above, it doesn't: it saves objects with parent, child and other (eg date, author, etc) information. In a truly distributed environment, the actual history will be different for every repository depending exactly how and when changes were fetched, merged or pushed.

    Rebasing is a good way to do a couple of things:

    1. "Squash" related commits in your local repository prior to a push (eg, "Implement feature X," "Tests for feature X" and, "Fix bugs found while testing feature X").
    2. Simplify merging branches and keeping up-to-date with remote changes during long periods between pushes.

    Squashing related commits:

    Keep up to date with remote branches without merging.

    git pull --rebase

    or

    git fetch <remote>
       git rebase <remote>/<branch>

    Resolving conflicts.

    Any pull, merge, or rebase operation can result in a conflict during the application of a particular change from the remote branch. Follow the on-screen instructions to resolve problems. This will usually consist of doing a git status to list conflicts, editing the files and using git add to mark each conflict resolved. The process must either be allowed to continue by issuing a git rebase --continue or git merge --continue command, or the operation can be reverted with --abort instead of --continue. If in doubt, copy your repository.

    Making a new remote branch.

    Tagging.

    Special notes on mis-tagging.

    There are several things that can go wrong with tagging:

    1. One can omit an intended -a option;
    2. One can misspell the tag; or
    3. One can omit or (horror!) fix a file and wish to update the tag.

    If you have not pushed tags yet (See above) then the fix is trivial: for the first two cases, remove the erroneous tag with git tag -d <tag>; for the third, re-tag with git tag -am <mesasge> [<tree-ish>]. However, if you have already pushed tags, there are wider consequences. For this reason, altering pushed tags is emphatically discouraged: create a new tag. However, since you're going to ignore me and do it anyway, here's how to do what you want without getting into too much of a mess:

    1. To remove an erroneous tag, someone with the manager rôle on the project must log into cdcvs directly as the repository user (e.g. p-art), cd to the bare repository with cd /cvs/projects/<project> and then remove the tag with git tag -d <tag>.
    2. Back in your working directory, tag correctly and then push tags.
    3. Now, you must alert all your developers that, if they have pulled the erroneous tag to their local repository, they will need to remove the tag from their local repository with git -d <tag> and then re-pull from the repository. Otherwise, deleted tags will keep re-appearing in the remote repository and/or users will be unable to pull or push to the remote.

    Undo the last commit:

    Recover deleted (committed files).

    Stage selected changes within a file.

    Tig: a simple and colored text-mode interface for Git

    Tig is a command line tool that wraps many Git browse operations (like log, diff, show, status) in a colored text-mode interface based on ncurses. Tig has been written by Jonas Fonseca.

    See the full Tig manual for a detailed description.

    Obtaining Tig

    Tig is available as package from many Linux distributions. On Debian/Ubuntu it is available with the package name tig from the default repositories.

    On RHEL-based systems it is available from the additional repository RepoForge.

    On OS X it is easily installed via Homebrew:

    brew install tig

    Tig pager mode

    Many git commands can be piped into tig. When tig is invoked this way, it is in pager mode: output will be colored according to the input format, and colored.

    For instance it is possible to pipe the differences of one file like this: 

    git diff path/to/file.cxx | tig

    or see the changes of one revision like this:

    git show b204d4c87 | tig

    The most important interactive tig commands are:

    Log view

    Tig invoked without any argument spawns a full log view with one line per commit including author, date and log message. Heads of the different branches are clearly indicated. To see a graph view indicating branching graphically (just like git log --oneline --graph), do:

    tig --all

    tig --all

    A log can be selected with Enter to see the revision changes.

    An example of useful application of the log view is interactive cherry-picking: just press 'C' to cherry-pick currently selected commit into your current branch.

    Blame view

    Blame view is extremely useful to see which lines were committed by whom. It is an improved version of the standard git blame command with a much clearer and interactive output.

    Each line can be selected to display the associated full commit log and diff.

    tig blame

    Usage:

    tig blame path/to/file.cxx

    Interactive staging and current status

    tig status opens an interactive display to quickly select files to be staged. Move over the file and press 'u' to (un)stage it.

    tig status

    The .gitconfig file

    This file contains global (~/.gitconfig) or repository-local configuration settings. You can (eg):

    See the attached .gitconfig example. Have fun!

    Reproduced with permission from the following page: https://cdcvs.fnal.gov/redmine/projects/cet-is-public/wiki/GitTipsAndTri... by Chris Green