projects / thirdparty / git.git / blame
| Commit | Line | Data |
|---|---|---|
| db9536c8 JH |
1 | Everyday GIT With 20 Commands Or So |
| 2 | =================================== | |
| 3 | ||
| 4 | GIT suite has over 100 commands, and the manual page for each of | |
| 5 | them discusses what the command does and how it is used in | |
| 6 | detail, but until you know what command should be used in order | |
| 7 | to achieve what you want to do, you cannot tell which manual | |
| 8 | page to look at, and if you know that already you do not need | |
| 9 | the manual. | |
| 10 | ||
| 11 | Does that mean you need to know all of them before you can use | |
| 12 | git? Not at all. Depending on the role you play, the set of | |
| 13 | commands you need to know is slightly different, but in any case | |
| 14 | what you need to learn is far smaller than the full set of | |
| 15 | commands to carry out your day-to-day work. This document is to | |
| 16 | serve as a cheat-sheet and a set of pointers for people playing | |
| 17 | various roles. | |
| 18 | ||
| 19 | <<Basic Repository>> commands are needed by people who has a | |
| 20 | repository --- that is everybody, because every working tree of | |
| 21 | git is a repository. | |
| 22 | ||
| 23 | In addition, <<Individual Developer (Standalone)>> commands are | |
| 24 | essential for anybody who makes a commit, even for somebody who | |
| 25 | works alone. | |
| 26 | ||
| 27 | If you work with other people, you will need commands listed in | |
| 28 | <<Individual Developer (Participant)>> section as well. | |
| 29 | ||
| 30 | People who play <<Integrator>> role need to learn some more | |
| 31 | commands in addition to the above. | |
| 32 | ||
| 33 | <<Repository Administration>> commands are for system | |
| 34 | administrators who are responsible to care and feed git | |
| 35 | repositories to support developers. | |
| 36 | ||
| 37 | ||
| 38 | Basic Repository[[Basic Repository]] | |
| 39 | ------------------------------------ | |
| 40 | ||
| 41 | Everybody uses these commands to feed and care git repositories. | |
| 42 | ||
| 43 | * gitlink:git-init-db[1] or gitlink:git-clone[1] to create a | |
| 44 | new repository. | |
| 45 | ||
| 46 | * gitlink:git-fsck-objects[1] to validate the repository. | |
| 47 | ||
| 48 | * gitlink:git-prune[1] to garbage collect crufts in the | |
| 49 | repository. | |
| 50 | ||
| 51 | * gitlink:git-repack[1] to pack loose objects for efficiency. | |
| 52 | ||
| 53 | Individual Developer (Standalone)[[Individual Developer (Standalone)]] | |
| 54 | ---------------------------------------------------------------------- | |
| 55 | ||
| 56 | A standalone individual developer does not exchange patches with | |
| 57 | other poeple, and works alone in a single repository, using the | |
| 58 | following commands. | |
| 59 | ||
| 60 | * gitlink:git-show-branch[1] to see where you are. | |
| 61 | ||
| 62 | * gitlink:git-diff[1] and gitlink:git-status[1] to see what | |
| 63 | you are in the middle of doing. | |
| 64 | ||
| 65 | * gitlink:git-log[1] to see what happened. | |
| 66 | ||
| 67 | * gitlink:git-whatchanged[1] to find out where things have | |
| 68 | come from. | |
| 69 | ||
| 70 | * gitlink:git-checkout[1] and gitlink:git-branch[1] to switch | |
| 71 | branches. | |
| 72 | ||
| 73 | * gitlink:git-update-index[1] to manage the index file. | |
| 74 | ||
| 75 | * gitlink:git-commit[1] to advance the current branch. | |
| 76 | ||
| 77 | * gitlink:git-reset[1] and gitlink:git-checkout[1] (with | |
| 78 | pathname parameters) to undo changes. | |
| 79 | ||
| 80 | * gitlink:git-pull[1] with "." as the remote to merge between | |
| 81 | local branches. | |
| 82 | ||
| 83 | * gitlink:git-rebase[1] to maintain topic branches. | |
| 84 | ||
| 85 | ||
| 86 | Individual Developer (Participant)[[Individual Developer (Participant)]] | |
| 87 | ------------------------------------------------------------------------ | |
| 88 | ||
| 89 | A developer working as a participant in a group project needs to | |
| 90 | learn how to communicate with others, and uses these commands in | |
| 91 | addition to the ones needed by a standalone developer. | |
| 92 | ||
| 93 | * gitlink:git-pull[1] from "origin" to keep up-to-date with | |
| 94 | the upstream. | |
| 95 | ||
| 96 | * gitlink:git-push[1] to shared repository if you adopt CVS | |
| 97 | style shared repository workflow. | |
| 98 | ||
| 99 | * gitlink:git-format-patch[1] to prepare e-mail submission, if | |
| 100 | you adopt Linux kernel-style public forum workflow. | |
| 101 | ||
| 102 | ||
| 103 | Integrator[[Integrator]] | |
| 104 | ------------------------ | |
| 105 | ||
| 106 | A fairly central person acting as the integrator in a group | |
| 107 | project receives changes made by others, reviews and integrates | |
| 108 | them and publishes the result for others to use, using these | |
| 109 | commands in addition to the ones needed by participants. | |
| 110 | ||
| 111 | * gitlink:git-am[1] to apply patches e-mailed in from your | |
| 112 | contributors. | |
| 113 | ||
| 114 | * gitlink:git-pull[1] to merge from your trusted lieutenants. | |
| 115 | ||
| 116 | * gitlink:git-format-patch[1] to prepare and send suggested | |
| 117 | alternative to contributors. | |
| 118 | ||
| 119 | * gitlink:git-revert[1] to undo botched commits. | |
| 120 | ||
| 121 | * gitlink:git-push[1] to publish the bleeding edge. | |
| 122 | ||
| 123 | ||
| 124 | Repository Administration[[Repository Administration]] | |
| 125 | ------------------------------------------------------ | |
| 126 | ||
| 127 | A repository administrator uses the following tools to set up | |
| 128 | and maintain access to the repository by developers. | |
| 129 | ||
| 130 | * gitlink:git-daemon[1] to allow anonymous download from | |
| 131 | repository. | |
| 132 | ||
| 133 | * gitlink:git-shell[1] can be used as a 'restricted login shell' | |
| 134 | for shared central repository users. | |
| 135 | ||
| 136 | * howto/update-hook-example has a good example of | |
| 137 | managing a shared central repository. | |
| 138 |