简体中文 ▾ 主题 ▾ 最新版本 ▾ giteveryday 最后更新于 2.43.0

名称

giteveryday - 适用于日常 Git 的有用命令集

概要

日常 Git 的大约 20 条命令

描述

为了在此描述一套适用于日常 Git 的有用命令，可以将 Git 用户大致分为四类。

独立开发者（独立工作）

独立的个人开发者不与其他任何人交换补丁，在单个仓库中独自工作，并使用以下命令。

示例

使用 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)

  1. 添加当前目录下的所有内容。

  2. 创建轻量级、未加注释的标签。

创建主题分支并进行开发。
$ git switch -c alsa-audio (1)
$ edit/compile/test
$ git restore 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 switch master (8)
$ git merge alsa-audio (9)
$ git log --since='3 days ago' (10)
$ git log v2.43.. curses/ (11)

  1. 创建新的主题分支。

  2. 撤销您在 curses/ux_audio_oss.c 中搞砸的更改。

  3. 您需要告诉 Git 是否添加了新文件；如果稍后执行 git commit -a，则会捕获删除和修改。

  4. 查看您要提交的更改。

  5. 提交所有已测试的内容，并附带您的签名。

  6. 查看您之前提交的所有更改。

  7. 使用您原始的消息，修改之前的提交，添加您所有的新更改。

  8. 切换到 master 分支。

  9. 将主题分支合并到您的 master 分支。

  10. 查看提交日志；其他限制输出的格式可以组合使用，包括 -10（显示最多 10 条提交）、--until=2005-12-10 等。

  11. 仅查看自 v2.43 标签以来，与 curses/ 目录相关的更改。

独立开发者（参与者）

作为团队项目参与者的开发者需要学习如何与他人沟通，并使用这些命令（除了独立开发者所需的命令之外）。

  • git-clone[1] 从上游克隆以初始化您的本地仓库。

  • git-pull[1] 和 git-fetch[1] 从“origin”获取以与上游保持同步。

  • git-push[1] 推送到共享仓库，如果您采用 CVS 风格的共享仓库工作流程。

  • git-format-patch[1] 用于准备电子邮件提交，如果您采用 Linux 内核风格的公共论坛工作流程。

  • git-send-email[1] 用于发送您的电子邮件提交，避免被您的 MUA 损坏。

  • git-request-pull[1] 用于创建更改摘要，供您的上游拉取。

示例

克隆上游并对其进行工作。将更改推向上游。
$ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
$ cd my2.6
$ git switch -c 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 switch 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)

  1. 从 master 检出一个新分支 mine。

  2. 根据需要重复。

  3. 从您的分支（相对于 master）提取补丁，

  4. 并通过电子邮件发送。

  5. 返回 master，准备查看有什么新内容

  6. git pull 默认从 origin 获取并将合并到当前分支。

  7. 拉取后立即查看自上次检查以来上游的更改，仅限于我们感兴趣的区域。

  8. 检查外部仓库中的分支名称（如果未知）。

  9. 从特定仓库的特定分支 ALL 中获取并合并。

  10. 撤销拉取。

  11. 垃圾回收从已撤销的拉取中遗留的对象。

推送到另一个仓库。
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 switch master
mothership$ git merge satellite/master (5)

  1. mothership 机器在您的主目录下有一个 frotz 仓库；从它克隆以在卫星机器上启动一个仓库。

  2. clone 默认设置了这些配置变量。它安排 git pull 获取并将 mothership 机器的分支存储在本地 remotes/origin/* 远程跟踪分支中。

  3. 安排 git push 将所有本地分支推送到 mothership 机器上对应的分支。

  4. push 将把我们在 remotes/satellite/* 远程跟踪分支上完成的所有工作暂存到 mothership 机器上。您可以使用此作为备份方法。同样，您可以假装 mothership 从您那里“获取”了（当访问是单向的时很有用）。

  5. 在 mothership 机器上，将卫星机器上完成的工作合并到 master 分支。

基于特定标签进行分支。
$ git switch -c 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)

  1. 创建一个基于已知（但有些落后）标签的私有分支。

  2. 将 private2.6.14 分支中的所有更改前向移植到 master 分支，而不进行正式的“合并”。或长格式
    git format-patch -k -m --stdout v2.6.14..private2.6.14 | git am -3 -k

另一种参与者提交机制是使用 git request-pull 或 pull-request 机制（例如，如 GitHub (www.github.com) 上所用），以通知您的上游您的贡献。

集成者

在团队项目中充当集成者的相对核心人物接收他人的更改，审查并集成它们，然后发布结果供他人使用，他使用这些命令（除了参与者所需的命令之外）。

此部分也可供那些响应 GitHub (www.github.com) 上的 git request-pull 或 pull-request 来将他人的工作集成到其历史中的人使用。存储库的子区域负责人将同时充当参与者和集成者。

示例

典型的集成者的 Git 日。
$ 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 switch -c topic/one master
$ git am -3 -i -s ./+to-apply (4)
$ compile/test
$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus (5)
$ git switch topic/one && git rebase master (6)
$ git switch -C seen next (7)
$ git merge topic/one topic/two && git merge hold/linus (8)
$ git switch 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 seen (11)
    do
	git show-branch ko/$branch $branch (12)
    done
$ git push --follow-tags ko (13)

  1. 查看您（如果有什么的话）正在进行的操作。

  2. 查看哪些分支尚未合并到 master。其他集成分支（例如 maint、next 和 seen）也类似。

  3. 阅读邮件，保存适用的邮件，并保存其他尚未准备好的邮件（其他邮件阅读器可用）。

  4. 交互式地应用它们，并附带您的签名。

  5. 根据需要创建主题分支并应用，同样附带签名。

  6. rebase 内部主题分支，该分支尚未合并到 master 或作为稳定分支的一部分公开。

  7. 每次从下一个开始重新启动 seen。

  8. 并捆绑仍在进行中的主题分支。

  9. backport 关键修复。

  10. 创建已签名的标签。

  11. 确保 master 没有被意外回溯到比已推送内容更早的版本。

  12. 在 git show-branch 的输出中，master 应该拥有 ko/master 的所有内容，并且 next 应该拥有 ko/next 的所有内容，依此类推。

  13. 推送最新的代码，以及指向已推送历史的新标签。

在此示例中，ko 简写指向 kernel.org 上的 Git 维护者的仓库，如下所示：

(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/seen
	push = refs/heads/maint

仓库管理

仓库管理员使用以下工具来设置和维护开发者对仓库的访问。

update hook howto 提供了管理共享中心仓库的一个很好的示例。

此外，还有许多其他广泛部署的托管、浏览和审查解决方案，例如

  • gitolite、gerrit code review、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 为开发者提供仅推送/拉取访问权限。

例如，使用：$ 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

  1. 登录 shell 设置为 /usr/bin/git-shell，它只允许 git push 和 git pull。用户需要 SSH 访问该机器。

  2. 在许多发行版中，/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

  1. 将开发者放入同一个 git 组。

  2. 并使共享仓库对组可写。

  3. 使用 Carl 提供的 update-hook 示例（位于 Documentation/howto/）进行分支策略控制。

  4. alice 和 cindy 可以推送到 master，只有 bob 可以推送到 doc-update。david 是发布经理，也是唯一可以创建和推送版本标签的人。

GIT

Git[1] 套件的一部分