The official Git documentation has the fantastic giteveryday guide, that can be found here:
This article reformats the referred guide.
The most basic workflow
- Checkout or create new branch
$git checkout -b <new_branch>
- Apply changes and commit
$git add .and
$git commit -m 'your comment'
- Merge changes from others
$git merge master
- Checkout master (or the branch you wish to merge into)
$git checkout master
- Merge the new branch
$git merge <new_branch>
- Delete the branch you no longer need or you can also continue to develop on the new branch, merging it in a later moment.
For the individual Developer (Standalone)
A standalone individual developer does not exchange patches with other people, and works alone in a single repository.
git-initto create a new repository.
git-logto see what happened.
git-branchto switch branches.
git-addto manage the index file.
git-statusto see what you are in the middle of doing.
git-committo advance the current branch.
git-checkout(with pathname parameters) to undo changes.
git-mergeto merge between local branches.
git-rebaseto maintain topic branches.
git-tagto mark a known point.
Initiate a local repository
- Use a tarball as a starting point for a new repository.
$ tar zxf frotz.tar.gz $ cd frotz $ git init
- Add everything under the current directory.
$ git add .
- Commit all files to local repository
$ git commit -m "import of frotz source tree."
- Make a lightweight, unannotated tag.
$ git tag v2.43
Create a topic branch and develop.
- Create a new topic branch.
$ git checkout -b alsa-audio $ edit/compile/test
- Revert your botched changes in curses/ux_audio_oss.c.
$ git checkout -- curses/ux_audio_oss.c
- You need to tell Git if you added a new file; removal and modification will be caught if you do git commit -a later.
$ git add curses/ux_audio_alsa.c $ edit/compile/test
- To see what changes you are committing.
$ git diff HEAD
- Commit everything, as you have tested, with your sign-off.
$ git commit -a -s $ edit/compile/test
- Look at all your changes including the previous commit.
$ git diff HEAD^
- Amend the previous commit, adding all your new changes, using your original message.
$ git commit -a --amend
- Switch to the master branch.
$ git checkout master
- Merge a topic branch into your master branch.
$ git merge alsa-audio
- Review commit logs; other forms to limit output can be combined and include -10 (to show up to 10 commits), –until=2005-12-10, etc.
$ git log --since='3 days ago'
- View only the changes that touch what’s in curses/ directory, since v2.43 tag.
$ git log v2.43.. curses/
Individual Developer (Participant)
A developer working as a participant in a group project needs to learn how to communicate with others, and uses these commands in addition to the ones needed by a standalone developer.
git-clonefrom the upstream to prime your local repository.
git-fetchfrom “origin” to keep up-to-date with the upstream.
git-pushto shared repository, if you adopt CVS style shared repository workflow.
git-format-patchto prepare e-mail submission, if you adopt Linux kernel-style public forum workflow.
git-send-emailto send your e-mail submission without corruption by your MUA.
git-request-pullto create a summary of changes for your upstream to pull.
Clone the upstream and work on it. Feed changes to upstream.
- Clone repository
$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6 $ cd my2.6
- checkout a new branch
$ git checkout -b mine master
- repeat as needed.
$ edit/compile/test; git commit -a -s
- extract patches from your branch, relative to master,
$ git format-patch master
- and email them.
$ git send-email --to="person <firstname.lastname@example.org>" 00*.patch
- return to master, ready to see what’s new
$ git checkout master
- git pull fetches from origin by default and merges into the current branch.
$ git pull
- immediately after pulling, look at the changes done upstream since last time we checked, only in the area we are interested in.
$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386
- check the branch names in an external repository (if not known).
$ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git
- fetch from a specific branch ALL from a specific repository and merge it.
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL
- revert the pull.
$ git reset --hard ORIG_HEAD
- garbage collect leftover objects from reverted pull.
$ git gc
Push into another repository.
- mothership machine has a frotz repository under your home directory; clone from it to start a repository on the satellite machine.
satellite$ git clone mothership:frotz frotz satellite$ cd frotz
- clone sets these configuration variables by default. It arranges
git pullto fetch and store the branches of mothership machine to local
satellite$ git config --get-regexp '^(remote|branch)\.' remote.origin.url mothership:frotz remote.origin.fetch refs/heads/*:refs/remotes/origin/* branch.master.remote origin branch.master.merge refs/heads/master
gitpush to push all local branches to their corresponding branch of the mothership machine.
satellite$ git config remote.origin.push \ +refs/heads/*:refs/remotes/satellite/* satellite$ edit/compile/test/commit
- push will stash all our work away on
remotes/satellite/*remote-tracking branches on the mothership machine. You could use this as a back-up method. Likewise, you can pretend that mothership “fetched” from you (useful when access is one sided).
satellite$ git push origin mothership$ cd frotz mothership$ git checkout master
- on mothership machine, merge the work done on the satellite machine into the master branch.
mothership$ git merge satellite/master
Branch off of a specific tag.
- create a private branch based on a well known (but somewhat behind) tag.
$ git checkout -b private2.6.14 v2.6.14 $ edit/compile/test; git commit -a $ git checkout master
- forward port all changes in private2.6.14 branch to master branch without a formal “merging”. Or longhand git format-patch -k -m –stdout v2.6.14..private2.6.14 | git am -3 -k
$ git cherry-pick v2.6.14..private2.6.14
An alternate participant submission mechanism is using the git request-pull or pull-request mechanisms (e.g as used on GitHub (www.github.com) to notify your upstream of your contribution.