forked from open-mpi/ompi
-
Notifications
You must be signed in to change notification settings - Fork 1
GitBestPractices
Jeff Squyres edited this page Jun 10, 2015
·
9 revisions
For a nice, relatively brief overview of Git's basic usage, please see the Pro Git book by Scott Chacon, available for free online. If you want to understand the nitty-gritty, check out Git From the Bottom Up. There's also a fantastic blog post at Github entitled How to undo almost anything in Git -- this is required reading.
Otherwise, here are a list of typical "dos" and "don'ts" for Git, some with a specific eye towards Open MPI:
- make smaller, logically self-contained commits
- write nice commit messages, with a concise subject line and a useful description of what change is being made and why
- (In general) Rebase your local work before pushing up to
ompi/master
instead of creating merge commits that say "Merge branch 'master' of 'ssh://...'
". Unfortunately, the default behavior ofgit pull
is to merge instead of rebase, see here for how to change that default. - If you think you screwed up a repository (yours or a shared one), STOP.
- See this Awesome flow chart on how to get out of Git messes
- Ask for help on [email protected]. Many Git operations are reversible if you don't take too many steps in the wrong direction.
- run
git gc
on your repository periodically, it will speed up many operations and shrink the space consumed on disk by your.git
directory
- change published history
- change published history!
- CHANGE PUBLISHED HISTORY!!
- push non-master branches to the main
ompi
repo - push non-master branches to the main
ompi
repo! - push with
--force
or--mirror
to the mainompi
repo - delete or rename published tags -- this is a real pain to unwind
- make large rambling commits that intermix multiple unrelated changes
- make unnecessary whitespace changes in the same commit where you are changing logic
- commit any large binaries to the repository, this will rapidly increase the storage space required for everybody's clones
- use
git filter-branch
unless you really know what you are doing, and especially don't use it on published history - use
git pull
instead ofgit pull --rebase
for normal local work that will be pushed up toompi/master
(see "Do" above