![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index b935c180881571a964356e63a2e718c2721b5e6b..e598cdda45cf0b953a106d6786765b3316e2cc16 100644 (file)
Everyday GIT With 20 Commands Or So
===================================
Everyday GIT With 20 Commands Or So
===================================
-GIT suite has over 100 commands, and the manual page for each of
-them discusses what the command does and how it is used in
-detail, but until you know what command should be used in order
-to achieve what you want to do, you cannot tell which manual
-page to look at, and if you know that already you do not need
-the manual.
-
-Does that mean you need to know all of them before you can use
-git? Not at all. Depending on the role you play, the set of
-commands you need to know is slightly different, but in any case
-what you need to learn is far smaller than the full set of
-commands to carry out your day-to-day work. This document is to
-serve as a cheat-sheet and a set of pointers for people playing
-various roles.
-
-<<Basic Repository>> commands are needed by people who has a
+<<Basic Repository>> commands are needed by people who have a
repository --- that is everybody, because every working tree of
git is a repository.
repository --- that is everybody, because every working tree of
git is a repository.
works alone.
If you work with other people, you will need commands listed in
works alone.
If you work with other people, you will need commands listed in
-<<Individual Developer (Participant)>> section as well.
+the <<Individual Developer (Participant)>> section as well.
-People who play <<Integrator>> role need to learn some more
+People who play the <<Integrator>> role need to learn some more
commands in addition to the above.
<<Repository Administration>> commands are for system
commands in addition to the above.
<<Repository Administration>> commands are for system
-administrators who are responsible to care and feed git
-repositories to support developers.
+administrators who are responsible for the care and feeding
+of git repositories.
Basic Repository[[Basic Repository]]
------------------------------------
Basic Repository[[Basic Repository]]
------------------------------------
-Everybody uses these commands to feed and care git repositories.
+Everybody uses these commands to maintain git repositories.
- * gitlink:git-init-db[1] or gitlink:git-clone[1] to create a
+ * linkgit:git-init[1] or linkgit:git-clone[1] to create a
new repository.
new repository.
- * gitlink:git-fsck-objects[1] to validate the repository.
+ * linkgit:git-fsck[1] to check the repository for errors.
- * gitlink:git-prune[1] to garbage collect cruft in the
- repository.
-
- * gitlink:git-repack[1] to pack loose objects for efficiency.
+ * linkgit:git-gc[1] to do common housekeeping tasks such as
+ repack and prune.
Examples
~~~~~~~~
Examples
~~~~~~~~
Check health and remove cruft.::
+
------------
Check health and remove cruft.::
+
------------
-$ git fsck-objects <1>
-$ git prune
+$ git fsck <1>
$ git count-objects <2>
$ git count-objects <2>
-$ git repack <3>
-$ git prune <4>
+$ git gc <3>
------------
+
------------
+
-<1> running without "--full" is usually cheap and assures the
+<1> running without `\--full` is usually cheap and assures the
repository health reasonably well.
<2> check how many loose objects there are and how much
disk space is wasted by not repacking.
repository health reasonably well.
<2> check how many loose objects there are and how much
disk space is wasted by not repacking.
-<3> without "-a" repacks incrementally. repacking every 4-5MB
-of loose objects accumulation may be a good rule of thumb.
-<4> after repack, prune removes the duplicate loose objects.
+<3> repacks the local repository and performs other housekeeping tasks.
Repack a small project into single pack.::
+
------------
Repack a small project into single pack.::
+
------------
-$ git repack -a -d <1>
-$ git prune
+$ git gc <1>
------------
+
------------
+
-<1> pack all the objects reachable from the refs into one pack
-and remove unneeded other packs
+<1> pack all the objects reachable from the refs into one pack,
+then remove the other packs.
Individual Developer (Standalone)[[Individual Developer (Standalone)]]
Individual Developer (Standalone)[[Individual Developer (Standalone)]]
other people, and works alone in a single repository, using the
following commands.
other people, and works alone in a single repository, using the
following commands.
- * gitlink:git-show-branch[1] to see where you are.
+ * linkgit:git-show-branch[1] to see where you are.
- * gitlink:git-log[1] to see what happened.
+ * linkgit:git-log[1] to see what happened.
- * gitlink:git-whatchanged[1] to find out where things have
- come from.
-
- * gitlink:git-checkout[1] and gitlink:git-branch[1] to switch
+ * linkgit:git-checkout[1] and linkgit:git-branch[1] to switch
branches.
branches.
- * gitlink:git-add[1] and gitlink:git-update-index[1] to manage
- the index file.
+ * linkgit:git-add[1] to manage the index file.
- * gitlink:git-diff[1] and gitlink:git-status[1] to see what
+ * linkgit:git-diff[1] and linkgit:git-status[1] to see what
you are in the middle of doing.
you are in the middle of doing.
- * gitlink:git-commit[1] to advance the current branch.
+ * linkgit:git-commit[1] to advance the current branch.
- * gitlink:git-reset[1] and gitlink:git-checkout[1] (with
+ * linkgit:git-reset[1] and linkgit:git-checkout[1] (with
pathname parameters) to undo changes.
pathname parameters) to undo changes.
- * gitlink:git-pull[1] with "." as the remote to merge between
- local branches.
+ * linkgit:git-merge[1] to merge between local branches.
- * gitlink:git-rebase[1] to maintain topic branches.
+ * linkgit:git-rebase[1] to maintain topic branches.
- * gitlink:git-tag[1] to mark known point.
+ * linkgit:git-tag[1] to mark known point.
Examples
~~~~~~~~
Examples
~~~~~~~~
-Extract a tarball and create a working tree and a new repository to keep track of it.::
+Use a tarball as a starting point for a new repository.::
+
------------
$ tar zxf frotz.tar.gz
$ cd frotz
+
------------
$ tar zxf frotz.tar.gz
$ cd frotz
-$ git-init-db
+$ git-init
$ git add . <1>
$ git add . <1>
-$ git commit -m 'import of frotz source tree.'
+$ git commit -m "import of frotz source tree."
$ git tag v2.43 <2>
------------
+
$ git tag v2.43 <2>
------------
+
$ git checkout -- curses/ux_audio_oss.c <2>
$ git add curses/ux_audio_alsa.c <3>
$ edit/compile/test
$ git checkout -- curses/ux_audio_oss.c <2>
$ git add curses/ux_audio_alsa.c <3>
$ edit/compile/test
-$ git diff <4>
+$ git diff HEAD <4>
$ git commit -a -s <5>
$ edit/compile/test
$ git reset --soft HEAD^ <6>
$ git commit -a -s <5>
$ edit/compile/test
$ git reset --soft HEAD^ <6>
$ git diff ORIG_HEAD <7>
$ git commit -a -c ORIG_HEAD <8>
$ git checkout master <9>
$ git diff ORIG_HEAD <7>
$ git commit -a -c ORIG_HEAD <8>
$ git checkout master <9>
-$ git pull . alsa-audio <10>
+$ git merge alsa-audio <10>
$ git log --since='3 days ago' <11>
$ git log v2.43.. curses/ <12>
------------
+
<1> create a new topic branch.
$ git log --since='3 days ago' <11>
$ git log v2.43.. curses/ <12>
------------
+
<1> create a new topic branch.
-<2> revert your botched changes in "curses/ux_audio_oss.c".
+<2> revert your botched changes in `curses/ux_audio_oss.c`.
<3> you need to tell git if you added a new file; removal and
<3> you need to tell git if you added a new file; removal and
-modification will be caught if you do "commit -a" later.
+modification will be caught if you do `git commit -a` later.
<4> to see what changes you are committing.
<5> commit everything as you have tested, with your sign-off.
<6> take the last commit back, keeping what is in the working tree.
<4> to see what changes you are committing.
<5> commit everything as you have tested, with your sign-off.
<6> take the last commit back, keeping what is in the working tree.
<8> redo the commit undone in the previous step, using the message
you originally wrote.
<9> switch to the master branch.
<8> redo the commit undone in the previous step, using the message
you originally wrote.
<9> switch to the master branch.
-<10> merge a topic branch into your master branch
+<10> merge a topic branch into your master branch.
<11> review commit logs; other forms to limit output can be
<11> review commit logs; other forms to limit output can be
-combined and include --max-count=10 (show 10 commits), --until='2005-12-10'.
-<12> view only the changes that touch what's in curses/
-directory, since v2.43 tag.
+combined and include `\--max-count=10` (show 10 commits),
+`\--until=2005-12-10`, etc.
+<12> view only the changes that touch what's in `curses/`
+directory, since `v2.43` tag.
Individual Developer (Participant)[[Individual Developer (Participant)]]
Individual Developer (Participant)[[Individual Developer (Participant)]]
learn how to communicate with others, and uses these commands in
addition to the ones needed by a standalone developer.
learn how to communicate with others, and uses these commands in
addition to the ones needed by a standalone developer.
- * gitlink:git-clone[1] from the upstream to prime your local
+ * linkgit:git-clone[1] from the upstream to prime your local
repository.
repository.
- * gitlink:git-pull[1] and gitlink:git-fetch[1] from "origin"
+ * linkgit:git-pull[1] and linkgit:git-fetch[1] from "origin"
to keep up-to-date with the upstream.
to keep up-to-date with the upstream.
- * gitlink:git-push[1] to shared repository, if you adopt CVS
+ * linkgit:git-push[1] to shared repository, if you adopt CVS
style shared repository workflow.
style shared repository workflow.
- * gitlink:git-format-patch[1] to prepare e-mail submission, if
+ * linkgit:git-format-patch[1] to prepare e-mail submission, if
you adopt Linux kernel-style public forum workflow.
Examples
you adopt Linux kernel-style public forum workflow.
Examples
$ edit/compile/test; git commit -a -s <1>
$ git format-patch origin <2>
$ git pull <3>
$ edit/compile/test; git commit -a -s <1>
$ git format-patch origin <2>
$ git pull <3>
-$ git whatchanged -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
+$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
$ git reset --hard ORIG_HEAD <6>
$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
$ git reset --hard ORIG_HEAD <6>
-$ git prune <7>
+$ git gc <7>
$ git fetch --tags <8>
------------
+
<1> repeat as needed.
<2> extract patches from your branch for e-mail submission.
$ git fetch --tags <8>
------------
+
<1> repeat as needed.
<2> extract patches from your branch for e-mail submission.
-<3> "pull" fetches from "origin" by default and merges into the
+<3> `git pull` fetches from `origin` by default and merges into the
current branch.
<4> immediately after pulling, look at the changes done upstream
since last time we checked, only in the
current branch.
<4> immediately after pulling, look at the changes done upstream
since last time we checked, only in the
<5> fetch from a specific branch from a specific repository and merge.
<6> revert the pull.
<7> garbage collect leftover objects from reverted pull.
<5> fetch from a specific branch from a specific repository and merge.
<6> revert the pull.
<7> garbage collect leftover objects from reverted pull.
-<8> from time to time, obtain official tags from the "origin"
-and store them under .git/refs/tags/.
+<8> from time to time, obtain official tags from the `origin`
+and store them under `.git/refs/tags/`.
Push into another repository.::
+
------------
Push into another repository.::
+
------------
-satellite$ git clone mothership:frotz/.git frotz <1>
+satellite$ git clone mothership:frotz frotz <1>
satellite$ cd frotz
satellite$ cd frotz
-satellite$ cat .git/remotes/origin <2>
-URL: mothership:frotz/.git
-Pull: master:origin
-satellite$ echo 'Push: master:satellite' >>.git/remotes/origin <3>
+satellite$ git config --get-regexp '^(remote|branch)\.' <2>
+remote.origin.url mothership:frotz
+remote.origin.fetch refs/heads/*:refs/remotes/origin/*
+branch.master.remote origin
+branch.master.merge refs/heads/master
+satellite$ git config remote.origin.push \
+ master:refs/remotes/satellite/master <3>
satellite$ edit/compile/test/commit
satellite$ git push origin <4>
mothership$ cd frotz
mothership$ git checkout master
satellite$ edit/compile/test/commit
satellite$ git push origin <4>
mothership$ cd frotz
mothership$ git checkout master
-mothership$ git pull . satellite <5>
+mothership$ git merge satellite/master <5>
------------
+
<1> mothership machine has a frotz repository under your home
directory; clone from it to start a repository on the satellite
machine.
------------
+
<1> mothership machine has a frotz repository under your home
directory; clone from it to start a repository on the satellite
machine.
-<2> clone creates this file by default. It arranges "git pull"
-to fetch and store the master branch head of mothership machine
-to local "origin" branch.
-<3> arrange "git push" to push local "master" branch to
-"satellite" branch of the mothership machine.
-<4> push will stash our work away on "satellite" branch on the
-mothership machine. You could use this as a back-up method.
+<2> clone sets these configuration variables by default.
+It arranges `git pull` to fetch and store the branches of mothership
+machine to local `remotes/origin/*` tracking branches.
+<3> arrange `git push` to push local `master` branch to
+`remotes/satellite/master` branch of the mothership machine.
+<4> push will stash our work away on `remotes/satellite/master`
+tracking branch on the mothership machine. You could use this as
+a back-up method.
<5> on mothership machine, merge the work done on the satellite
machine into the master branch.
<5> on mothership machine, merge the work done on the satellite
machine into the master branch.
+
<1> create a private branch based on a well known (but somewhat behind)
tag.
+
<1> create a private branch based on a well known (but somewhat behind)
tag.
-<2> forward port all changes in private2.6.14 branch to master branch
+<2> forward port all changes in `private2.6.14` branch to `master` branch
without a formal "merging".
without a formal "merging".
them and publishes the result for others to use, using these
commands in addition to the ones needed by participants.
them and publishes the result for others to use, using these
commands in addition to the ones needed by participants.
- * gitlink:git-am[1] to apply patches e-mailed in from your
+ * linkgit:git-am[1] to apply patches e-mailed in from your
contributors.
contributors.
- * gitlink:git-pull[1] to merge from your trusted lieutenants.
+ * linkgit:git-pull[1] to merge from your trusted lieutenants.
- * gitlink:git-format-patch[1] to prepare and send suggested
+ * linkgit:git-format-patch[1] to prepare and send suggested
alternative to contributors.
alternative to contributors.
- * gitlink:git-revert[1] to undo botched commits.
+ * linkgit:git-revert[1] to undo botched commits.
- * gitlink:git-push[1] to publish the bleeding edge.
+ * linkgit:git-push[1] to publish the bleeding edge.
Examples
Examples
& s 2 3 4 5 ./+to-apply
& s 7 8 ./+hold-linus
& q
& s 2 3 4 5 ./+to-apply
& s 7 8 ./+hold-linus
& q
-$ git checkout master
+$ git checkout -b topic/one master
$ git am -3 -i -s -u ./+to-apply <4>
$ compile/test
$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5>
$ git checkout topic/one && git rebase master <6>
$ git am -3 -i -s -u ./+to-apply <4>
$ compile/test
$ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5>
$ git checkout topic/one && git rebase master <6>
-$ git checkout pu && git reset --hard master <7>
-$ git pull . topic/one topic/two && git pull . hold/linus <8>
+$ git checkout pu && git reset --hard next <7>
+$ git merge topic/one topic/two && git merge hold/linus <8>
$ git checkout maint
$ git cherry-pick master~4 <9>
$ compile/test
$ git checkout maint
$ git cherry-pick master~4 <9>
$ compile/test
-$ git tag -s -m 'GIT 0.99.9x' v0.99.9x <10>
+$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
$ git fetch ko && git show-branch master maint 'tags/ko-*' <11>
$ git push ko <12>
$ git push ko v0.99.9x <13>
$ git fetch ko && git show-branch master maint 'tags/ko-*' <11>
$ git push ko <12>
$ git push ko v0.99.9x <13>
that are not quite ready.
<4> apply them, interactively, with my sign-offs.
<5> create topic branch as needed and apply, again with my
that are not quite ready.
<4> apply them, interactively, with my sign-offs.
<5> create topic branch as needed and apply, again with my
-sign-offs.
+sign-offs.
<6> rebase internal topic branch that has not been merged to the
master, nor exposed as a part of a stable branch.
<6> rebase internal topic branch that has not been merged to the
master, nor exposed as a part of a stable branch.
-<7> restart "pu" every time from the master.
+<7> restart `pu` every time from the next.
<8> and bundle topic branches still cooking.
<9> backport a critical fix.
<10> create a signed tag.
<11> make sure I did not accidentally rewind master beyond what I
<8> and bundle topic branches still cooking.
<9> backport a critical fix.
<10> create a signed tag.
<11> make sure I did not accidentally rewind master beyond what I
-already pushed out. "ko" shorthand points at the repository I have
+already pushed out. `ko` shorthand points at the repository I have
at kernel.org, and looks like this:
+
------------
$ cat .git/remotes/ko
URL: kernel.org:/pub/scm/git/git.git
Pull: master:refs/tags/ko-master
at kernel.org, and looks like this:
+
------------
$ cat .git/remotes/ko
URL: kernel.org:/pub/scm/git/git.git
Pull: master:refs/tags/ko-master
+Pull: next:refs/tags/ko-next
Pull: maint:refs/tags/ko-maint
Push: master
Pull: maint:refs/tags/ko-maint
Push: master
+Push: next
Push: +pu
Push: maint
------------
+
Push: +pu
Push: maint
------------
+
-In the output from "git show-branch", "master" should have
-everything "ko-master" has.
+In the output from `git show-branch`, `master` should have
+everything `ko-master` has, and `next` should have
+everything `ko-next` has.
<12> push out the bleeding edge.
<13> push the tag out, too.
<12> push out the bleeding edge.
<13> push the tag out, too.
A repository administrator uses the following tools to set up
and maintain access to the repository by developers.
A repository administrator uses the following tools to set up
and maintain access to the repository by developers.
- * gitlink:git-daemon[1] to allow anonymous download from
+ * linkgit:git-daemon[1] to allow anonymous download from
repository.
repository.
- * gitlink:git-shell[1] can be used as a 'restricted login shell'
+ * linkgit:git-shell[1] can be used as a 'restricted login shell'
for shared central repository users.
link:howto/update-hook-example.txt[update hook howto] has a good
for shared central repository users.
link:howto/update-hook-example.txt[update hook howto] has a good
Examples
~~~~~~~~
Examples
~~~~~~~~
+We assume the following in /etc/services::
++
+------------
+$ grep 9418 /etc/services
+git 9418/tcp # Git Version Control System
+------------
+
Run git-daemon to serve /pub/scm from inetd.::
+
------------
$ grep git /etc/inetd.conf
git stream tcp nowait nobody \
Run git-daemon to serve /pub/scm from inetd.::
+
------------
$ grep git /etc/inetd.conf
git stream tcp nowait nobody \
- /usr/bin/git-daemon git-daemon --inetd --syslog --export-all /pub/scm
+ /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
------------
+
The actual configuration line should be on one line.
------------
+
The actual configuration line should be on one line.
wait = no
user = nobody
server = /usr/bin/git-daemon
wait = no
user = nobody
server = /usr/bin/git-daemon
- server_args = --inetd --syslog --export-all --base-path=/pub/scm
+ server_args = --inetd --export-all --base-path=/pub/scm
log_on_failure += USERID
}
------------
log_on_failure += USERID
}
------------
------------
+
<1> log-in shell is set to /usr/bin/git-shell, which does not
------------
+
<1> log-in shell is set to /usr/bin/git-shell, which does not
-allow anything but "git push" and "git pull". The users should
+allow anything but `git push` and `git pull`. The users should
get an ssh access to the machine.
<2> in many distributions /etc/shells needs to list what is used
as the login shell.
get an ssh access to the machine.
<2> in many distributions /etc/shells needs to list what is used
as the login shell.