1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
\r
2 "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
\r
3 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
\r
5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
\r
6 <meta name="generator" content="AsciiDoc 7.0.2" />
\r
7 <style type="text/css">
\r
9 p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {
\r
11 border: 1px solid red;
\r
16 margin: 1em 5% 1em 5%;
\r
20 a:visited { color: fuchsia; }
\r
34 h1, h2, h3, h4, h5, h6 {
\r
36 font-family: sans-serif;
\r
38 margin-bottom: 0.5em;
\r
43 border-bottom: 2px solid silver;
\r
46 border-bottom: 2px solid silver;
\r
56 border: 1px solid silver;
\r
61 margin-bottom: 0.5em;
\r
71 font-family: sans-serif;
\r
78 font-family: sans-serif;
\r
82 font-family: sans-serif;
\r
84 border-top: 2px solid silver;
\r
90 padding-bottom: 0.5em;
\r
94 padding-bottom: 0.5em;
\r
98 div.tableblock, div.imageblock, div.exampleblock, div.verseblock,
\r
99 div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
\r
100 div.admonitionblock {
\r
103 margin-bottom: 1.5em;
\r
105 div.admonitionblock {
\r
107 margin-bottom: 2.5em;
\r
110 div.content { /* Block element content. */
\r
114 /* Block element titles. */
\r
115 div.title, caption.title {
\r
116 font-family: sans-serif;
\r
120 margin-bottom: 0.5em;
\r
126 td div.title:first-child {
\r
129 div.content div.title:first-child {
\r
132 div.content + div.title {
\r
136 div.sidebarblock > div.content {
\r
137 background: #ffffee;
\r
138 border: 1px solid silver;
\r
142 div.listingblock > div.content {
\r
143 border: 1px solid silver;
\r
144 background: #f4f4f4;
\r
148 div.quoteblock > div.content {
\r
149 padding-left: 2.0em;
\r
151 div.quoteblock .attribution {
\r
155 div.admonitionblock .icon {
\r
156 vertical-align: top;
\r
159 text-decoration: underline;
\r
161 padding-right: 0.5em;
\r
163 div.admonitionblock td.content {
\r
164 padding-left: 0.5em;
\r
165 border-left: 2px solid silver;
\r
168 div.exampleblock > div.content {
\r
169 border-left: 2px solid silver;
\r
173 div.verseblock div.content {
\r
177 div.imageblock div.content { padding-left: 0; }
\r
178 div.imageblock img { border: 1px solid silver; }
\r
179 span.image img { border-style: none; }
\r
183 margin-bottom: 0.8em;
\r
188 font-style: italic;
\r
190 dd > *:first-child {
\r
195 list-style-position: outside;
\r
198 list-style-type: lower-alpha;
\r
201 div.tableblock > table {
\r
202 border-color: #527bbd;
\r
206 font-family: sans-serif;
\r
215 margin-bottom: 0.8em;
\r
218 vertical-align: top;
\r
219 font-style: italic;
\r
220 padding-right: 0.8em;
\r
223 vertical-align: top;
\r
227 div#footer-badges { display: none; }
\r
229 /* Workarounds for IE6's broken and incomplete CSS2. */
\r
231 div.sidebar-content {
\r
232 background: #ffffee;
\r
233 border: 1px solid silver;
\r
236 div.sidebar-title, div.image-title {
\r
237 font-family: sans-serif;
\r
240 margin-bottom: 0.5em;
\r
243 div.listingblock div.content {
\r
244 border: 1px solid silver;
\r
245 background: #f4f4f4;
\r
249 div.quoteblock-content {
\r
250 padding-left: 2.0em;
\r
253 div.exampleblock-content {
\r
254 border-left: 2px solid silver;
\r
255 padding-left: 0.5em;
\r
258 <title>Everyday GIT With 20 Commands Or So</title>
\r
262 <h1>Everyday GIT With 20 Commands Or So</h1>
\r
264 <div id="preamble">
\r
265 <div class="sectionbody">
\r
266 <p>GIT suite has over 100 commands, and the manual page for each of
\r
267 them discusses what the command does and how it is used in
\r
268 detail, but until you know what command should be used in order
\r
269 to achieve what you want to do, you cannot tell which manual
\r
270 page to look at, and if you know that already you do not need
\r
272 <p>Does that mean you need to know all of them before you can use
\r
273 git? Not at all. Depending on the role you play, the set of
\r
274 commands you need to know is slightly different, but in any case
\r
275 what you need to learn is far smaller than the full set of
\r
276 commands to carry out your day-to-day work. This document is to
\r
277 serve as a cheat-sheet and a set of pointers for people playing
\r
279 <p><a href="#Basic Repository">[Basic Repository]</a> commands are needed by people who has a
\r
280 repository --- that is everybody, because every working tree of
\r
281 git is a repository.</p>
\r
282 <p>In addition, <a href="#Individual Developer (Standalone)">[Individual Developer (Standalone)]</a> commands are
\r
283 essential for anybody who makes a commit, even for somebody who
\r
285 <p>If you work with other people, you will need commands listed in
\r
286 <a href="#Individual Developer (Participant)">[Individual Developer (Participant)]</a> section as well.</p>
\r
287 <p>People who play <a href="#Integrator">[Integrator]</a> role need to learn some more
\r
288 commands in addition to the above.</p>
\r
289 <p><a href="#Repository Administration">[Repository Administration]</a> commands are for system
\r
290 administrators who are responsible to care and feed git
\r
291 repositories to support developers.</p>
\r
294 <h2>Basic Repository<a id="Basic Repository"></a></h2>
\r
295 <div class="sectionbody">
\r
296 <p>Everybody uses these commands to feed and care git repositories.</p>
\r
300 <a href="git-init-db.html">git-init-db(1)</a> or <a href="git-clone.html">git-clone(1)</a> to create a
\r
306 <a href="git-fsck-objects.html">git-fsck-objects(1)</a> to validate the repository.
\r
311 <a href="git-prune.html">git-prune(1)</a> to garbage collect crufts in the
\r
317 <a href="git-repack.html">git-repack(1)</a> to pack loose objects for efficiency.
\r
324 Check health and remove cruft.
\r
327 <div class="listingblock">
\r
328 <div class="content">
\r
329 <pre><tt>$ git fsck-objects <b>(1)</b>
\r
331 $ git count-objects <b>(2)</b>
\r
332 $ git repack <b>(3)</b>
\r
333 $ git prune <b>(4)</b></tt></pre>
\r
338 running without "—full" is usually cheap and assures the
\r
339 repository health reasonably well.
\r
344 check how many loose objects there are and how much
\r
345 diskspace is wasted by not repacking.
\r
350 without "-a" repacks incrementally. repacking every 4-5MB
\r
351 of loose objects accumulation may be a good rule of thumb.
\r
356 after repack, prune removes the duplicate loose objects.
\r
362 Repack a small project into single pack.
\r
365 <div class="listingblock">
\r
366 <div class="content">
\r
367 <pre><tt>$ git repack -a -d <b>(1)</b>
\r
368 $ git prune</tt></pre>
\r
373 pack all the objects reachable from the refs into one pack
\r
374 and remove unneeded other packs
\r
381 <h2>Individual Developer (Standalone)<a id="Individual Developer (Standalone)"></a></h2>
\r
382 <div class="sectionbody">
\r
383 <p>A standalone individual developer does not exchange patches with
\r
384 other poeple, and works alone in a single repository, using the
\r
385 following commands.</p>
\r
389 <a href="git-show-branch.html">git-show-branch(1)</a> to see where you are.
\r
394 <a href="git-log.html">git-log(1)</a> to see what happened.
\r
399 <a href="git-whatchanged.html">git-whatchanged(1)</a> to find out where things have
\r
405 <a href="git-checkout.html">git-checkout(1)</a> and <a href="git-branch.html">git-branch(1)</a> to switch
\r
411 <a href="git-add.html">git-add(1)</a> and <a href="git-update-index.html">git-update-index(1)</a> to manage
\r
417 <a href="git-diff.html">git-diff(1)</a> and <a href="git-status.html">git-status(1)</a> to see what
\r
418 you are in the middle of doing.
\r
423 <a href="git-commit.html">git-commit(1)</a> to advance the current branch.
\r
428 <a href="git-reset.html">git-reset(1)</a> and <a href="git-checkout.html">git-checkout(1)</a> (with
\r
429 pathname parameters) to undo changes.
\r
434 <a href="git-pull.html">git-pull(1)</a> with "." as the remote to merge between
\r
440 <a href="git-rebase.html">git-rebase(1)</a> to maintain topic branches.
\r
445 <a href="git-tag.html">git-tag(1)</a> to mark known point.
\r
452 Extract a tarball and create a working tree and a new repository to keep track of it.
\r
455 <div class="listingblock">
\r
456 <div class="content">
\r
457 <pre><tt>$ tar zxf frotz.tar.gz
\r
460 $ git add . <b>(1)</b>
\r
461 $ git commit -m 'import of frotz source tree.'
\r
462 $ git tag v2.43 <b>(2)</b></tt></pre>
\r
467 add everything under the current directory.
\r
472 make a lightweight, unannotated tag.
\r
478 Create a topic branch and develop.
\r
481 <div class="listingblock">
\r
482 <div class="content">
\r
483 <pre><tt>$ git checkout -b alsa-audio <b>(1)</b>
\r
484 $ edit/compile/test
\r
485 $ git checkout -- curses/ux_audio_oss.c <b>(2)</b>
\r
486 $ git add curses/ux_audio_alsa.c <b>(3)</b>
\r
487 $ edit/compile/test
\r
488 $ git diff <b>(4)</b>
\r
489 $ git commit -a -s <b>(5)</b>
\r
490 $ edit/compile/test
\r
491 $ git reset --soft HEAD^ <b>(6)</b>
\r
492 $ edit/compile/test
\r
493 $ git diff ORIG_HEAD <b>(7)</b>
\r
494 $ git commit -a -c ORIG_HEAD <b>(8)</b>
\r
495 $ git checkout master <b>(9)</b>
\r
496 $ git pull . alsa-audio <b>(10)</b>
\r
497 $ git log --since='3 days ago' <b>(11)</b>
\r
498 $ git log v2.43.. curses/ <b>(12)</b></tt></pre>
\r
503 create a new topic branch.
\r
508 revert your botched changes in "curses/ux_audio_oss.c".
\r
513 you need to tell git if you added a new file; removal and
\r
514 modification will be caught if you do "commit -a" later.
\r
519 to see what changes you are committing.
\r
524 commit everything as you have tested, with your sign-off.
\r
529 take the last commit back, keeping what is in the working tree.
\r
534 look at the changes since the premature commit we took back.
\r
539 redo the commit undone in the previous step, using the message
\r
540 you originally wrote.
\r
545 switch to the master branch.
\r
550 merge a topic branch into your master branch
\r
555 review commit logs; other forms to limit output can be
\r
556 combined and include —max-count=10 (show 10 commits), —until=<em>2005-12-10</em>.
\r
561 view only the changes that touch what's in curses/
\r
562 directory, since v2.43 tag.
\r
569 <h2>Individual Developer (Participant)<a id="Individual Developer (Participant)"></a></h2>
\r
570 <div class="sectionbody">
\r
571 <p>A developer working as a participant in a group project needs to
\r
572 learn how to communicate with others, and uses these commands in
\r
573 addition to the ones needed by a standalone developer.</p>
\r
577 <a href="git-clone.html">git-clone(1)</a> from the upstream to prime your local
\r
583 <a href="git-pull.html">git-pull(1)</a> and <a href="git-fetch.html">git-fetch(1)</a> from "origin"
\r
584 to keep up-to-date with the upstream.
\r
589 <a href="git-push.html">git-push(1)</a> to shared repository, if you adopt CVS
\r
590 style shared repository workflow.
\r
595 <a href="git-format-patch.html">git-format-patch(1)</a> to prepare e-mail submission, if
\r
596 you adopt Linux kernel-style public forum workflow.
\r
603 Clone the upstream and work on it. Feed changes to upstream.
\r
606 <div class="listingblock">
\r
607 <div class="content">
\r
608 <pre><tt>$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
\r
610 $ edit/compile/test; git commit -a -s <b>(1)</b>
\r
611 $ git format-patch origin <b>(2)</b>
\r
612 $ git pull <b>(3)</b>
\r
613 $ git whatchanged -p ORIG_HEAD.. arch/i386 include/asm-i386 <b>(4)</b>
\r
614 $ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <b>(5)</b>
\r
615 $ git reset --hard ORIG_HEAD <b>(6)</b>
\r
616 $ git prune <b>(7)</b>
\r
617 $ git fetch --tags <b>(8)</b></tt></pre>
\r
627 extract patches from your branch for e-mail submission.
\r
632 "pull" fetches from "origin" by default and merges into the
\r
638 immediately after pulling, look at the changes done upstream
\r
639 since last time we checked, only in the
\r
640 area we are interested in.
\r
645 fetch from a specific branch from a specific repository and merge.
\r
655 garbage collect leftover objects from reverted pull.
\r
660 from time to time, obtain official tags from the "origin"
\r
661 and store them under .git/refs/tags/.
\r
667 Push into another repository.
\r
670 <div class="listingblock">
\r
671 <div class="content">
\r
672 <pre><tt>satellite$ git clone mothership:frotz/.git frotz <b>(1)</b>
\r
673 satellite$ cd frotz
\r
674 satellite$ cat .git/remotes/origin <b>(2)</b>
\r
675 URL: mothership:frotz/.git
\r
676 Pull: master:origin
\r
677 satellite$ echo 'Push: master:satellite' >>.git/remotes/origin <b>(3)</b>
\r
678 satellite$ edit/compile/test/commit
\r
679 satellite$ git push origin <b>(4)</b>
\r
681 mothership$ cd frotz
\r
682 mothership$ git checkout master
\r
683 mothership$ git pull . satellite <b>(5)</b></tt></pre>
\r
688 mothership machine has a frotz repository under your home
\r
689 directory; clone from it to start a repository on the satellite
\r
695 clone creates this file by default. It arranges "git pull"
\r
696 to fetch and store the master branch head of mothership machine
\r
697 to local "origin" branch.
\r
702 arrange "git push" to push local "master" branch to
\r
703 "satellite" branch of the mothership machine.
\r
708 push will stash our work away on "satellite" branch on the
\r
709 mothership machine. You could use this as a back-up method.
\r
714 on mothership machine, merge the work done on the satellite
\r
715 machine into the master branch.
\r
721 Branch off of a specific tag.
\r
724 <div class="listingblock">
\r
725 <div class="content">
\r
726 <pre><tt>$ git checkout -b private2.6.14 v2.6.14 <b>(1)</b>
\r
727 $ edit/compile/test; git commit -a
\r
728 $ git checkout master
\r
729 $ git format-patch -k -m --stdout v2.6.14..private2.6.14 |
\r
730 git am -3 -k <b>(2)</b></tt></pre>
\r
735 create a private branch based on a well known (but somewhat behind)
\r
741 forward port all changes in private2.6.14 branch to master branch
\r
742 without a formal "merging".
\r
749 <h2>Integrator<a id="Integrator"></a></h2>
\r
750 <div class="sectionbody">
\r
751 <p>A fairly central person acting as the integrator in a group
\r
752 project receives changes made by others, reviews and integrates
\r
753 them and publishes the result for others to use, using these
\r
754 commands in addition to the ones needed by participants.</p>
\r
758 <a href="git-am.html">git-am(1)</a> to apply patches e-mailed in from your
\r
764 <a href="git-pull.html">git-pull(1)</a> to merge from your trusted lieutenants.
\r
769 <a href="git-format-patch.html">git-format-patch(1)</a> to prepare and send suggested
\r
770 alternative to contributors.
\r
775 <a href="git-revert.html">git-revert(1)</a> to undo botched commits.
\r
780 <a href="git-push.html">git-push(1)</a> to publish the bleeding edge.
\r
787 My typical GIT day.
\r
790 <div class="listingblock">
\r
791 <div class="content">
\r
792 <pre><tt>$ git status <b>(1)</b>
\r
793 $ git show-branch <b>(2)</b>
\r
795 & s 2 3 4 5 ./+to-apply
\r
796 & s 7 8 ./+hold-linus
\r
798 $ git checkout master
\r
799 $ git am -3 -i -s -u ./+to-apply <b>(4)</b>
\r
801 $ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <b>(5)</b>
\r
802 $ git checkout topic/one && git rebase master <b>(6)</b>
\r
803 $ git checkout pu && git reset --hard master <b>(7)</b>
\r
804 $ git pull . topic/one topic/two && git pull . hold/linus <b>(8)</b>
\r
805 $ git checkout maint
\r
806 $ git cherry-pick master~4 <b>(9)</b>
\r
808 $ git tag -s -m 'GIT 0.99.9x' v0.99.9x <b>(10)</b>
\r
809 $ git fetch ko && git show-branch master maint 'tags/ko-*' <b>(11)</b>
\r
810 $ git push ko <b>(12)</b>
\r
811 $ git push ko v0.99.9x <b>(13)</b></tt></pre>
\r
816 see what I was in the middle of doing, if any.
\r
821 see what topic branches I have and think about how ready
\r
827 read mails, save ones that are applicable, and save others
\r
828 that are not quite ready.
\r
833 apply them, interactively, with my sign-offs.
\r
838 create topic branch as needed and apply, again with my
\r
844 rebase internal topic branch that has not been merged to the
\r
845 master, nor exposed as a part of a stable branch.
\r
850 restart "pu" every time from the master.
\r
855 and bundle topic branches still cooking.
\r
860 backport a critical fix.
\r
865 create a signed tag.
\r
870 make sure I did not accidentally rewind master beyond what I
\r
871 already pushed out. "ko" shorthand points at the repository I have
\r
872 at kernel.org, and looks like this:
\r
873 $ cat .git/remotes/ko
\r
874 URL: kernel.org:/pub/scm/git/git.git
\r
875 Pull: master:refs/tags/ko-master
\r
876 Pull: maint:refs/tags/ko-maint
\r
880 In the output from "git show-branch", "master" should have
\r
881 everything "ko-master" has.
\r
886 push out the bleeding edge.
\r
891 push the tag out, too.
\r
898 <h2>Repository Administration<a id="Repository Administration"></a></h2>
\r
899 <div class="sectionbody">
\r
900 <p>A repository administrator uses the following tools to set up
\r
901 and maintain access to the repository by developers.</p>
\r
905 <a href="git-daemon.html">git-daemon(1)</a> to allow anonymous download from
\r
911 <a href="git-shell.html">git-shell(1)</a> can be used as a <em>restricted login shell</em>
\r
912 for shared central repository users.
\r
916 <p><a href="howto/update-hook-example.txt">update hook howto</a> has a good
\r
917 example of managing a shared central repository.</p>
\r
921 Run git-daemon to serve /pub/scm from inetd.
\r
924 <div class="listingblock">
\r
925 <div class="content">
\r
926 <pre><tt>$ grep git /etc/inet.conf
\r
927 git stream tcp nowait nobody \
\r
928 /usr/bin/git-daemon git-daemon --inetd --syslog --export-all /pub/scm</tt></pre>
\r
930 <p>The actual configuration line should be on one line.</p>
\r
933 Give push/pull only access to developers.
\r
936 <div class="listingblock">
\r
937 <div class="content">
\r
938 <pre><tt>$ grep git /etc/passwd <b>(1)</b>
\r
939 alice:x:1000:1000::/home/alice:/usr/bin/git-shell
\r
940 bob:x:1001:1001::/home/bob:/usr/bin/git-shell
\r
941 cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
\r
942 david:x:1003:1003::/home/david:/usr/bin/git-shell
\r
943 $ grep git /etc/shells <b>(2)</b>
\r
944 /usr/bin/git-shell</tt></pre>
\r
949 log-in shell is set to /usr/bin/git-shell, which does not
\r
950 allow anything but "git push" and "git pull". The users should
\r
951 get an ssh access to the machine.
\r
956 in many distributions /etc/shells needs to list what is used
\r
957 as the login shell.
\r
963 CVS-style shared repository.
\r
966 <div class="listingblock">
\r
967 <div class="content">
\r
968 <pre><tt>$ grep git /etc/group <b>(1)</b>
\r
969 git:x:9418:alice,bob,cindy,david
\r
970 $ cd /home/devo.git
\r
972 lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master
\r
973 drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches
\r
974 -rw-rw-r-- 1 david git 84 Dec 4 22:40 config
\r
975 -rw-rw-r-- 1 david git 58 Dec 4 22:40 description
\r
976 drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks
\r
977 -rw-rw-r-- 1 david git 37504 Dec 4 22:40 index
\r
978 drwxrwsr-x 2 david git 4096 Dec 4 22:40 info
\r
979 drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects
\r
980 drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs
\r
981 drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes
\r
982 $ ls -l hooks/update <b>(3)</b>
\r
983 -r-xr-xr-x 1 david git 3536 Dec 4 22:40 update
\r
984 $ cat info/allowed-users <b>(4)</b>
\r
985 refs/heads/master alice\|cindy
\r
986 refs/heads/doc-update bob
\r
987 refs/tags/v[0-9]* david</tt></pre>
\r
992 place the developers into the same git group.
\r
997 and make the shared repository writable by the group.
\r
1002 use update-hook example by Carl from Documentation/howto/
\r
1003 for branch policy control.
\r
1008 alice and cindy can push into master, only bob can push into doc-update.
\r
1009 david is the release manager and is the only person who can
\r
1010 create and push version tags.
\r
1016 HTTP server to support dumb protocol transfer.
\r
1019 <div class="listingblock">
\r
1020 <div class="content">
\r
1021 <pre><tt>dev$ git update-server-info <b>(1)</b>
\r
1022 dev$ ftp user@isp.example.com <b>(2)</b>
\r
1023 ftp> cp -r .git /home/user/myproject.git</tt></pre>
\r
1028 make sure your info/refs and objects/info/packs are up-to-date
\r
1033 upload to public HTTP server hosted by your ISP.
\r
1041 <div id="footer-text">
\r
1042 Last updated 29-Apr-2006 07:01:35 UTC
\r
projects / git.git / blob