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

名称

giteveryday - 日常 Git 的有用最小命令集

概要

日常 Git 的大约 20 个命令

描述

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

独立开发者（Standalone）

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

示例

使用 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 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. 主控机器在你的主目录下有一个 frotz 仓库；从它克隆以在卫星机器上启动一个仓库。

  2. clone 默认设置这些配置变量。它安排 git pull 从主控机器拉取并存储其分支到本地 remotes/origin/* 远程跟踪分支。

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

  4. 推送会将我们所有的工作存储在主控机器上的 remotes/satellite/* 远程跟踪分支上。你可以将其用作备份方法。同样，你可以假装主控机器从你这里“拉取”了（在单向访问时很有用）。

  5. 在主控机器上，将卫星机器上完成的工作合并到 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. 对尚未合并到 master 或作为稳定分支一部分暴露的内部主题分支进行 rebase。

  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

仓库管理

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

更新钩子教程 提供了一个管理共享中心仓库的好示例。

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

  • gitolite, gerrit code review, cgit 等。

示例

我们假设 /etc/services 中有以下内容
$ grep 9418 /etc/services
git		9418/tcp		# Git Version Control System
从 inetd 运行 git-daemon 以提供 /pub/scm 服务。
$ grep git /etc/inetd.conf
git	stream	tcp	nowait	nobody \
  /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm

实际配置行应该写在一行上。

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

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

GIT

Git[1] 套件的一部分

scroll-to-top