Everyday GIT With 20 Commands Or So
GIT suite 包含了 100 個以上的指令，而各指令的 manual page 中說明了該指令的功用以及使用的細節；但除非你知道用哪一個指令達成你想要做的事，不然壓根不知道要從哪一個 manual page 看起；反之，如果你已經知道要從哪個 manual 看起，那你大概也不需要看 manual 了。
難道這意指在使用 git 前，你必需瞭解每一個指令的用法嗎？其實不然。依據你的角色的不同，需要瞭解的指令也有些許的差異；但是不論扮演什麼樣的角色，你只要學一小部份的指令，就已足夠每日所需。這份文件的目的是成為一份密技表，以及為各種角色提供一個 git 的入口。
只要你有 repository，你就會需要 [Basic Repository] 中提到的指令 --- 其實這意指每個人都要看，因為 git 的每一個 working tree 都是一個 repository。
再來，只要有 commit 的需求，[Individual Developer (Standalone)] 中提到的指令就是你需要的，不論這個 repository 是否有提供他人存取。
如果你和他人合作，你也會需要 [Individual Developer (Participant)] 中提到的指令。
擔任 [Integrator] 角色的朋友，除了上面提到的以外，還需要多學一點。
[Repository Administration] 中提到的，則是給那些負責協助開發人員維護及交流 git repositories 的系統管理員所需要知道的。
Basic Repository
我們用這些指令來維護及操作 git repositories。
-
git-init-db(1) 或是 git-clone(1) 用來創建一個新的 repository。
-
git-fsck-objects(1) 用來驗證 repository。
-
git-prune(1) 用來處理 repository 的資源回收。
-
git-repack(1) 用來將散開的 objects 包裝起來以提升效率。
Examples
- 檢查 repository 是否有問題，並移除無用的部份
-
$ git fsck-objects (1)
$ git prune
$ git count-objects (2)
$ git repack (3)
$ git prune (4)-
這裡我們沒有使用 "—full"，一般來說這比較節省執行時使用的資源，並且可以保證 repository 的健康程度在合理的範圍內。
-
檢查散落的 objects 數量，並且回報如果不把它們打包會浪費多少資源。
-
因為沒有用 "-a"，git 會使用累進式打包。依照經驗，以累積的方式每 4-5MB 打包散落的 objects 可以有不錯的成效。
-
在打包後，使用 prune 來移除重覆的散落 objects。
-
- Repack a small project into single pack.
-
$ git repack -a -d (1)
$ git prune-
pack all the objects reachable from the refs into one pack and remove unneeded other packs
-
Individual Developer (Standalone)
A standalone individual developer does not exchange patches with other people, and works alone in a single repository, using the following commands.
-
git-show-branch(1) to see where you are.
-
git-log(1) to see what happened.
-
git-whatchanged(1) to find out where things have come from.
-
git-checkout(1) and git-branch(1) to switch branches.
-
git-add(1) and git-update-index(1) to manage the index file.
-
git-diff(1) and git-status(1) to see what you are in the middle of doing.
-
git-commit(1) to advance the current branch.
-
git-reset(1) and git-checkout(1) (with pathname parameters) to undo changes.
-
git-pull(1) with "." as the remote to merge between local branches.
-
git-rebase(1) to maintain topic branches.
-
git-tag(1) to mark known point.
Examples
- Extract a tarball and create a working tree and a new repository to keep track of it.
-
$ tar zxf frotz.tar.gz
$ cd frotz
$ git-init-db
$ git add . (1)
$ git commit -m 'import of frotz source tree.'
$ git tag v2.43 (2)-
add everything under the current directory.
-
make a lightweight, unannotated tag.
-
- Create a topic branch and develop.
-
$ git checkout -b alsa-audio (1)
$ 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 commit -a -s (5)
$ edit/compile/test
$ git reset --soft HEAD^ (6)
$ 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 log --since='3 days ago' (11)
$ git log v2.43.. curses/ (12)-
create a new topic branch.
-
revert your botched changes in "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 "commit -a" later.
-
to see what changes you are committing.
-
commit everything as you have tested, with your sign-off.
-
take the last commit back, keeping what is in the working tree.
-
look at the changes since the premature commit we took back.
-
redo the commit undone in the previous step, using the message you originally wrote.
-
switch to the master branch.
-
merge a topic branch into your master branch
-
review commit logs; other forms to limit output can be combined and include —max-count=10 (show 10 commits), —until=2005-12-10.
-
view only the changes that touch what's in curses/ directory, since v2.43 tag.
-
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-clone(1) from the upstream to prime your local repository.
-
git-pull(1) and git-fetch(1) from "origin" to keep up-to-date with the upstream.
-
git-push(1) to shared repository, if you adopt CVS style shared repository workflow.
-
git-format-patch(1) to prepare e-mail submission, if you adopt Linux kernel-style public forum workflow.
Examples
- Clone the upstream and work on it. Feed changes to upstream.
-
$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
$ 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 pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL (5)
$ git reset --hard ORIG_HEAD (6)
$ git prune (7)
$ git fetch --tags (8)-
repeat as needed.
-
extract patches from your branch for e-mail submission.
-
"pull" fetches from "origin" by default and merges into the current branch.
-
immediately after pulling, look at the changes done upstream since last time we checked, only in the area we are interested in.
-
fetch from a specific branch from a specific repository and merge.
-
revert the pull.
-
garbage collect leftover objects from reverted pull.
-
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$ 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$ edit/compile/test/commit
satellite$ git push origin (4)
mothership$ cd frotz
mothership$ git checkout master
mothership$ git pull . satellite (5)-
mothership machine has a frotz repository under your home directory; clone from it to start a repository on the satellite machine.
-
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.
-
arrange "git push" to push local "master" branch to "satellite" branch of the mothership machine.
-
push will stash our work away on "satellite" branch on the mothership machine. You could use this as a back-up method.
-
on mothership machine, merge the work done on the satellite machine into the master branch.
-
- Branch off of a specific tag.
-
$ git checkout -b private2.6.14 v2.6.14 (1)
$ edit/compile/test; git commit -a
$ git checkout master
$ git format-patch -k -m --stdout v2.6.14..private2.6.14 |
git am -3 -k (2)-
create a private branch based on a well known (but somewhat behind) tag.
-
forward port all changes in private2.6.14 branch to master branch without a formal "merging".
-
Integrator
A fairly central person acting as the integrator in a group project receives changes made by others, reviews and integrates them and publishes the result for others to use, using these commands in addition to the ones needed by participants.
-
git-am(1) to apply patches e-mailed in from your contributors.
-
git-pull(1) to merge from your trusted lieutenants.
-
git-format-patch(1) to prepare and send suggested alternative to contributors.
-
git-revert(1) to undo botched commits.
-
git-push(1) to publish the bleeding edge.
Examples
- My typical GIT day.
-
$ git status (1)
$ git show-branch (2)
$ mailx (3)
& s 2 3 4 5 ./+to-apply
& s 7 8 ./+hold-linus
& q
$ git checkout 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 maint
$ git cherry-pick master~4 (9)
$ compile/test
$ 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)-
see what I was in the middle of doing, if any.
-
see what topic branches I have and think about how ready they are.
-
read mails, save ones that are applicable, and save others that are not quite ready.
-
apply them, interactively, with my sign-offs.
-
create topic branch as needed and apply, again with my sign-offs.
-
rebase internal topic branch that has not been merged to the master, nor exposed as a part of a stable branch.
-
restart "pu" every time from the master.
-
and bundle topic branches still cooking.
-
backport a critical fix.
-
create a signed tag.
-
make sure I did not accidentally rewind master beyond what I 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: maintIn the output from "git show-branch", "master" should have everything "ko-master" has.
-
push out the bleeding edge.
-
push the tag out, too.
-
Repository Administration
A repository administrator uses the following tools to set up and maintain access to the repository by developers.
-
git-daemon(1) to allow anonymous download from repository.
-
git-shell(1) can be used as a restricted login shell for shared central repository users.
update hook howto has a good example of managing a shared central repository.
Examples
- 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/scmThe 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 --syslog --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.
-
$ grep git /etc/passwd (1)
alice:x:1000:1000::/home/alice:/usr/bin/git-shell
bob:x:1001:1001::/home/bob:/usr/bin/git-shell
cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
david:x:1003:1003::/home/david:/usr/bin/git-shell
$ grep git /etc/shells (2)
/usr/bin/git-shell-
log-in shell is set to /usr/bin/git-shell, which does not allow anything but "git push" and "git pull". The users should get an ssh access to the machine.
-
in many distributions /etc/shells needs to list what is used as the login shell.
-
- CVS-style shared repository.
-
$ grep git /etc/group (1)
git:x:9418:alice,bob,cindy,david
$ cd /home/devo.git
$ ls -l (2)
lrwxrwxrwx 1 david git 17 Dec 4 22:40 HEAD -> refs/heads/master
drwxrwsr-x 2 david git 4096 Dec 4 22:40 branches
-rw-rw-r-- 1 david git 84 Dec 4 22:40 config
-rw-rw-r-- 1 david git 58 Dec 4 22:40 description
drwxrwsr-x 2 david git 4096 Dec 4 22:40 hooks
-rw-rw-r-- 1 david git 37504 Dec 4 22:40 index
drwxrwsr-x 2 david git 4096 Dec 4 22:40 info
drwxrwsr-x 4 david git 4096 Dec 4 22:40 objects
drwxrwsr-x 4 david git 4096 Nov 7 14:58 refs
drwxrwsr-x 2 david git 4096 Dec 4 22:40 remotes
$ ls -l hooks/update (3)
-r-xr-xr-x 1 david git 3536 Dec 4 22:40 update
$ cat info/allowed-users (4)
refs/heads/master alice\|cindy
refs/heads/doc-update bob
refs/tags/v[0-9]* david-
place the developers into the same git group.
-
and make the shared repository writable by the group.
-
use update-hook example by Carl from Documentation/howto/ for branch policy control.
-
alice and cindy can push into master, only bob can push into doc-update. david is the release manager and is the only person who can create and push version tags.
-
- HTTP server to support dumb protocol transfer.
-
dev$ git update-server-info (1)
dev$ ftp user@isp.example.com (2)
ftp> cp -r .git /home/user/myproject.git-
make sure your info/refs and objects/info/packs are up-to-date
-
upload to public HTTP server hosted by your ISP.
-
