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

名称

giteveryday - Everyday Git 的一个有用的最小命令集

概要

包含大约 20 个命令的日常 Git

描述

为了在这里描述一小组用于日常 Git 的有用命令，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 仓库；从中克隆以在 satellite 机器上启动一个仓库。

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

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

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

  5. 在 mothership 机器上，将 satellite 机器上完成的工作合并到 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 或拉取请求机制（例如，在 GitHub (www.github.com) 上使用）来通知您的上游您的贡献。

集成者

一个在团队项目中充当集成者的相当中心的人物会收到其他人所做的更改，审查并集成它们，并发布结果供其他人使用，除了参与者需要的命令之外，还需要使用这些命令。

那些响应 GitHub (www.github.com) 上的 git request-pull 或拉取请求以将他人的工作集成到其历史记录中的人也可以使用本节。仓库的子区域负责人将同时充当参与者和集成者。

示例

典型的集成者的 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. 重新设置尚未合并到 master 或作为稳定分支的一部分公开的内部主题分支。

  7. 每次从 next 重新启动 seen。

  8. 并捆绑仍在处理中的主题分支。

  9. 向后移植关键修复。

  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

仓库管理

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

更新钩子 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 进行 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

  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. 使用 Documentation/howto/ 中 Carl 提供的 update-hook 示例进行分支策略控制。

  4. alice 和 cindy 可以 push 到 master 分支，只有 bob 可以 push 到 doc-update 分支。david 是发布管理员，是唯一可以创建和 push 版本标签的人。

GIT

属于 git[1] 套件的一部分

scroll-to-top