GitUse
Git Use
Resources
This book is essential reading for users of all levels [[1]]
Common Tasks
I'm presuming you know how to:
- clone a repo
- make a branch, and switch between branches
- commit changes
- create a patchset for review, and mail that patchset to a mailing list
- create a pull request
I can expand on any of those if needed.
Principles
A) One patch one change. E.g. don't change the URLs in the HTML and the indenting in the same patch, first do the whitespace changes, then do the content changes. This requires self control, but is made much easier one you know how to split your edits into multiple commits. (See below) B) In a patchset, do non-functional cleanup/cosmetic changes, or anything that will make the subsequent patches easier to review, first. Then do bugfix changes. Then do feature adds. C) One patch one change. D) Write meaningful commit messages. [[2]] [[3]] E) One patch one change. I mean it.
Do not worry about having lots of small patches - every single one will hopefully be utterly trivial to review and verify to be correct.
Splitting Edits Into Multiple Commits
You've changed several things in a single, or multiple files, and you realise that really they ought to be in separate patches. Solution:
- git add -p
You can select each hunk, and even recurse into each hunk if it includes multiple changed parts. Once you've added all the bits that belong in the first patch:
- git commit -s
Add your meaningful commit message, then GOTO 10
Undoiing a change you've just committed
Undo it in the editor, and then use git add (possibly add -p as above) to stage that change, and then git commit --amend to squash that change into the previous commit.
Rewriting History
You can edit old commit messages, tweak old patches, squash two adjacent patches together, and even reorder the patches with git rebase -i
To re-order the last 6 patches:
- git rebase -i HEAD~6
If the patches touch the same code, you might need to deal with merge conflicts - search for <<< in the affected file(s), git add that file(s), then git rebase --continue. If the conflicts are too hard to resolve - just abort the whole rebase with git merge --abort
Do not rewrite any history that you've shared with anyone else, so anything that you've pushed to an externally-facing repo.
It is possible to do all kinds of clever things in the middle of a rebase. Sometimes you can get carried away and forget you're in the middle of a rebase. This can lead to confusion, and the inability to do various things, so I find it best to keep my rebases quick and simple, done in one session.
...