X-Git-Url: https://git.tokkee.org/?a=blobdiff_plain;f=Documentation%2Feveryday.txt;h=08c61b1f1ac6ca880c6c3a4f311f65486aabd23e;hb=732bcf942c6e99879349711fd29b5062a704e248;hp=2ad2d61300f6656affb4512d2825efca9b26b178;hpb=16a4c6ee0d9a3d07d4d0afbbc4e3467e78065eca;p=git.git diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt index 2ad2d6130..08c61b1f1 100644 --- a/Documentation/everyday.txt +++ b/Documentation/everyday.txt @@ -1,22 +1,7 @@ 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. - -<> commands are needed by people who has a +<> commands are needed by people who have a repository --- that is everybody, because every working tree of git is a repository. @@ -25,51 +10,53 @@ essential for anybody who makes a commit, even for somebody who works alone. If you work with other people, you will need commands listed in -<> section as well. +the <> section as well. -People who play <> role need to learn some more +People who play the <> role need to learn some more commands in addition to the above. <> 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]] ------------------------------------ -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 + * gitlink:git-init[1] or gitlink:git-clone[1] to create a new repository. - * gitlink:git-fsck-objects[1] to validate the repository. + * gitlink:git-fsck[1] to check the repository for errors. - * gitlink:git-prune[1] to garbage collect crufts in the - repository. + * gitlink:git-prune[1] to remove unused objects in the repository. * gitlink:git-repack[1] to pack loose objects for efficiency. + * gitlink:git-gc[1] to do common housekeeping tasks such as + repack and prune. + Examples ~~~~~~~~ Check health and remove cruft.:: + ------------ -$ git fsck-objects <1> -$ git prune +$ git fsck <1> $ git count-objects <2> $ git repack <3> -$ git prune <4> +$ git gc <4> ------------ + -<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. -<3> without "-a" repacks incrementally. repacking every 4-5MB +<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. +<4> it is easier to use `git gc` than individual housekeeping commands +such as `prune` and `repack`. This runs `repack -a -d`. Repack a small project into single pack.:: + @@ -78,8 +65,8 @@ $ git repack -a -d <1> $ git prune ------------ + -<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)]] @@ -93,14 +80,10 @@ following commands. * gitlink: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 branches. - * gitlink:git-add[1] and gitlink:git-update-index[1] to manage - the index file. + * gitlink:git-add[1] to manage the index file. * gitlink:git-diff[1] and gitlink:git-status[1] to see what you are in the middle of doing. @@ -110,8 +93,7 @@ following commands. * gitlink:git-reset[1] and gitlink:git-checkout[1] (with pathname parameters) to undo changes. - * gitlink:git-pull[1] with "." as the remote to merge between - local branches. + * gitlink:git-merge[1] to merge between local branches. * gitlink:git-rebase[1] to maintain topic branches. @@ -120,12 +102,12 @@ following commands. 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 -$ git-init-db +$ git-init $ git add . <1> $ git commit -m 'import of frotz source tree.' $ git tag v2.43 <2> @@ -142,7 +124,7 @@ $ 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> @@ -150,15 +132,15 @@ $ edit/compile/test $ 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. -<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 -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. @@ -166,11 +148,12 @@ modification will be caught if you do "commit -a" later. <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 -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)]] @@ -203,7 +186,7 @@ $ cd my2.6 $ 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 prune <7> @@ -212,7 +195,7 @@ $ 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 @@ -220,37 +203,41 @@ area we are interested in. <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.:: + ------------ -satellite$ git clone mothership:frotz/.git frotz <1> +satellite$ git clone mothership:frotz frotz <1> 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 -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. -<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. @@ -266,7 +253,7 @@ $ git format-patch -k -m --stdout v2.6.14..private2.6.14 | + <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". @@ -303,13 +290,13 @@ $ mailx <3> & 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 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 @@ -326,25 +313,33 @@ they are. 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. -<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 -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 - Pull: maint:refs/tags/ko-maint - Push: master - Push: +pu - Push: maint -In the output from "git show-branch", "master" should have -everything "ko-master" has. ++ +------------ +$ 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 +Push: next +Push: +pu +Push: maint +------------ ++ +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. @@ -367,16 +362,46 @@ example of managing a shared central repository. 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 \ - /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. +Run git-daemon to serve /pub/scm from xinetd.:: ++ +------------ +$ cat /etc/xinetd.d/git-daemon +# default: off +# description: The git server offers access to git repositories +service git +{ + disable = no + type = UNLISTED + port = 9418 + socket_type = stream + wait = no + user = nobody + server = /usr/bin/git-daemon + server_args = --inetd --export-all --base-path=/pub/scm + log_on_failure += USERID +} +------------ ++ +Check your xinetd(8) documentation and setup, this is from a Fedora system. +Others might be different. + Give push/pull only access to developers.:: + ------------ @@ -390,7 +415,7 @@ $ grep git /etc/shells <2> ------------ + <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.