©
本文档使用 PHP中文网手册 发布
giteveryday - Everyday Git 的一组有用的最小命令
每天 Git 有20个命令或者如此
Git 用户可以大致分为四类，用于描述日常 Git 的一小部分有用命令。
个人开发者（独立）命令对于任何进行提交的人都是必不可少的，即使对于单独工作的人也是如此。
如果您与其他人一起工作，您还需要个人开发者（参与者）部分中列出的命令。
扮演集成角色的人除了需要上面的内容外，还需要学习更多的命令。
存储库管理命令用于负责照顾和提供 Git 存储库的系统管理员。
独立的个人开发人员不会与其他人交换补丁，并使用以下命令单独在单个资源库中工作。
git-init [1]创建一个新的存储库。
git-log [1]看看发生了什么。
git-checkout [1]和git-branch [1]来切换分支。
git-add [1]来管理索引文件。
git-diff [1]和git-status [1]来查看你在做什么。
git-commit [1]推进当前分支。
git-reset [1]和git-checkout [1]（带路径名参数）撤销更改。
git-merge [1]在本地分支之间合并。
git-rebase [1]维护主题分支。
git-tag [1]标记已知点。
使用 tarball 作为新存储库的起点。
$ tar zxf frotz.tar.gz $ cd frotz $ git init $ git add . (1)$ git commit -m "import of frotz source tree."$ git tag v2.43 (2)
在当前目录下添加所有内容。
制作一个轻量级，不带标签的标签。
创建主题分支并进行开发。
$ 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 HEAD (4)$ git commit -a -s (5)$ edit/compile/test $ git diff HEAD^ (6)$ git commit -a --amend (7)$ git checkout master (8)$ git merge alsa-audio (9)$ git log --since='3 days ago' (10)$ git log v2.43.. curses/ (11)
创建一个新的主题分支。
恢复你的拙劣的变化curses/ux_audio_oss.c。
如果你添加了一个新文件，你需要告诉Git; 如果您git commit -a稍后再做，删除和修改将会被捕获。
查看您正在提交的更改。
按照您的测试，承诺您的签名。
查看所有更改，包括以前的提交。
修改以前的提交，使用原始消息添加所有新的更改。
切换到主分支。
将主题分支合并到您的主分支中。
审查提交日志; 限制输出的其他形式可以组合并包括-10（最多显示10次提交）--until=2005-12-10等。
curses/由于v2.43标记，只查看触及目录内容的更改。
作为团队项目参与者的开发人员需要学习如何与他人沟通，并使用这些命令以及独立开发人员所需的命令。
git-clone [1] 从上游迁移到本地存储库。
git-pull [1] 和 git-fetch [1]从 “origin” 与上游保持同步。
如果您采用 CVS 风格的共享存储库工作流，请将 git-push [1] 共享存储库。
git-format-patch [1] 准备电子邮件提交，如果你采用 Linux 内核式的公共论坛工作流程。
git-send-email [1] 发送您的电子邮件提交没有由您的 MUA 腐败。
git-request-pull [1] 为你的上游创建一个变更摘要。
克隆上游并开始工作。Feed 更改为上游。
$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6$ cd my2.6$ git checkout -b mine master (1)$ edit/compile/test; git commit -a -s (2)$ git format-patch master (3)$ git send-email --to="person <email@example.com>" 00*.patch (4)$ git checkout master (5)$ git pull (6)$ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 (7)$ git ls-remote --heads http://git.kernel.org/.../jgarzik/libata-dev.git (8)$ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL (9)$ git reset --hard ORIG_HEAD (10)$ git gc (11)
mine从主人结帐一个新的分支。
根据需要重复。
从你的分支中提取补丁，相对于主，
并给他们发邮件。
返回master，准备好看看有什么新鲜事
git pull从origin默认提取并合并到当前分支。
在拉动后立即查看自上次检查以来上游所做的更改，仅限于我们感兴趣的区域。
检查外部存储库中的分支名称（如果未知）。
从ALL特定存储库的特定分支中获取并合并它。
恢复拉力。
垃圾收集回复拉的剩余物品。
推入另一个存储库。
satellite$ git clone mothership:frotz frotz (1)satellite$ cd frotz 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 \ +refs/heads/*:refs/remotes/satellite/* (3) satellite$ edit/compile/test/commit satellite$ git push origin (4) mothership$ cd frotz mothership$ git checkout master mothership$ git merge satellite/master (5)
母机在您的主目录下有一个 frotz 存储库; 从它克隆到在卫星机器上启动存储库。
克隆默认设置这些配置变量。它安排git pull将母机分支机构存放到当地的remotes/origin/*远程追踪分支机构。
安排git push将所有当地分支机构推到母机的相应分支。
推动将把我们所有的工作都remotes/satellite/*放在母机上的远程跟踪分支上。你可以用它作为备份方法。同样，你可以假装母亲从你身上“获取”（当访问是单方面时很有用）。
在母机上，将在卫星机器上完成的工作合并到主分支中。
分支出一个特定的标签。
$ git checkout -b private2.6.14 v2.6.14 (1)$ edit/compile/test; git commit -a $ git checkout master $ git cherry-pick v2.6.14..private2.6.14 (2)
创建一个基于众所周知的（但有点落后的）标签的私人分支。
将private2.6.14分支中的所有更改转发到master分支，而无需正式的“合并”。或者是徒手画 git format-patch -k -m --stdout v2.6.14..private2.6.14 | git am -3 -k
另一个参与者提交机制正在使用git request-pull或拉请求机制（例如 GitHub（www.github.com）上使用的机制来通知您上游的贡献。
作为集体项目集成者的一个相当中心的人接收其他人所做的更改，审核并整合他们，并将结果发布给其他人使用，除了参与者需要的命令之外，还使用这些命令。
这部分内容也可供那些git request-pull对 GitHub（www.github.com）作出响应或请求将其他人的工作整合到其历史中的人使用。储存库的一个子区域中尉将扮演参与者和集成者的角色。
git-am [1] 应用从您的贡献者电子邮件发送的补丁。
git-pull [1] 从你信任的副手中合并。
git-format-patch [1] 准备并向贡献者发送推荐替代方案。
git-revert [1] 撤消拙劣的提交。
git-push [1] 发布出血的边缘。
典型并集成的 Git day。
$ git status (1)$ git branch --no-merged master (2)$ mailx (3)& s 2 3 4 5 ./+to-apply& s 7 8 ./+hold-linus& q $ git checkout -b topic/one master $ git am -3 -i -s ./+to-apply (4)$ compile/test $ git checkout -b hold/linus && git am -3 -i -s ./+hold-linus (5)$ git checkout topic/one && git rebase master (6)$ 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 tag -s -m "GIT 0.99.9x" v0.99.9x (10)$ git fetch ko && for branch in master maint next pu (11) do git show-branch ko/$branch $branch (12) done $ git push --follow-tags ko (13)
看看你中间部分做了些什么，如果有的话。
看哪些分支还没有合并到master。同样，对于任何其他集成分支如maint，next和pu（潜在的更新）。
阅读邮件，保存适用的邮件，并保存其他未准备好的邮件（其他邮件阅读器可用）。
以交互方式将它们应用于您的签名。
根据需要创建主题分支并再次应用签名。
rebase 内部主题分支尚未合并到主或作为稳定分支的一部分公开。
pu每次从下一次重新启动。
并捆绑主题分支仍在烹饪。
支持重要的修复。
创建一个签名标签。
确保主人不会意外地重新超出已经推出的水平。
在输出中git show-branch，master应该拥有一切ko/master，并且next应该拥有一切ko/next，等等。
推出流血的边缘，以及指向推送历史的新标签。
在这个例子中，ko简写指向 Git 维护者在 kernel.org 的仓库，看起来像这样：
(in .git/config)[remote "ko"] url = kernel.org:/pub/scm/git/git.git fetch = refs/heads/*:refs/remotes/ko/* push = refs/heads/master push = refs/heads/next push = +refs/heads/pu push = refs/heads/maint
存储库管理员使用以下工具来设置和维护开发人员对存储库的访问。
git-daemon [1] 允许匿名从版本库下载。
git-shell [1] 可以用作restricted login shell共享中央资源库用户。
git-http-backend [1] 提供了允许提取和推送服务的 Git-over-HTTP（“Smart http”）的服务器端实现。
gitweb [1] 为 Git 存储库提供了 Web 前端，可以使用 git-instaweb [1] 脚本进行设置。
更新 hook howto 有一个管理共享中央存储库的好例子。
此外，还有其他一些广泛部署的托管，浏览和审查解决方案，例如：
gitolite，gerrit 代码审查，cgit 和其他。
我们在 / etc / services 的假设如下
$ grep 9418 /etc/services git 9418/tcp # Git Version Control System
运行 git-daemon 来从 inetd 提供 / pub / scm 。
$ grep git /etc/inetd.conf git stream tcp nowait nobody \ /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
实际的配置线应该在一条线上。
运行 git-daemon 以从 xinetd 提供 / pub / scm 。
$ 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}检查你的 xinetd（8）文档和设置，这是来自 Fedora 系统。其他可能不同。
给使用 git-over-ssh 的开发人员提供 push/pull 的访问权限。
例如那些使用： $ git push/pull ssh://host.xz/pub/scm/project
$ 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
登录 shell 设置为 / usr / bin / git-shell ，它不允许任何内容git push和git pull。用户需要 ssh 访问机器。
在许多发行版中，/ etc / shells 需要列出用作登录 shell 的内容。
CVS 风格的共享库。
$ 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
将开发人员放入同一个 git 组中。
并使共享存储库可由组写入。
使用来自 Documentation / howto / for 分支策略控制的 Carl 的更新钩子示例。
爱丽丝和辛迪可以推进主人，只有鲍勃可以推入文档更新。david 是发布经理，是唯一可以创建和推送版本标签的人。