- http://up-for-grabs.net/ (英)
- http://www.firsttimersonly.com/ (英)
- GitHub 上的(仅)初学者标签 (英)
- "仅初学者"博文 (英)
- Git Community Book 中文版
- git-tips: 英文版 | 中文版
想看看开发者的第一个 Pull Request 是什么?查看 http://firstpr.me/
我简要地整理一下你在此课程中学到的所有非常棒的新技能。现在,你已经知道:
- 如何设置远程仓库
- 如何将更改推送到远程仓库并从中获取更改
- 如何 fork 仓库
- 开始处理新功能或项目更改前,要采取的初步步骤
- 如何创建 Pull Request
- 了解与项目其他利益相关者清楚、频繁沟通的重要性
小结
git rebase
命令可以用来做很多事情。
# 交互式 rebase
$ git rebase -i <base>
# 交互式地将 commit 变基到我们当前所在的 commit 向前三个的 commit
$ git rebase -i HEAD~3
在 commit 的交互式列表中,所有 commit 都以 pick
开头,但你可以使用其他命令(reword
、edit
、squash
、fixup
、exec
和 drop
)进行变换。
我建议你在变基之前创建一个备份(backup)分支,这样便能很容易返回到之前的状态。如果你对变基的结果满意,则可以删除 backup
分支!
何时变基
可以看到,git rebase
命令非常强大。它可以帮助你编辑提交说明、重新排序 commit、合并 commit 等,真的是一款非常强大的工具。现在的问题是"应该何时进行变基?"。
每当你对 commit 进行变基,Git 将为每个 commit 创建一个新的 SHA!这有很大的影响。对于 Git,SHA 为 commit 的标识符,因此不同的标识符代表着不同的 commit,无论内容是否发生了变化。
如果你已推送了你想进行变基的 commit,则不应变基。如果你在与其他开发者协作,那么他们可能已经在使用你推送的 commit。如果你随后使用 git rebase
来进行更改,并强行推送 commit,则其他开发者现在将无法与远程仓库同步。他们需要对自己的 Git 仓库进行一些复杂的手术,使它们的仓库回到工作状态……甚至可能连这一点都做不了;他们可能得抛弃之前的所有工作,使用你新变基过且强制推送的 commit 重新开始。
git rebase
使用 git rebase
会创建一个具有新 SHA 的新 commit。当我尝试使用 git push
将此 commit 推送至 GitHub 时,GitHub 知道接受此推送会删除那三个单独 commit,所以它拒绝了。因此,我不得不使用 git push -f
强制推送这些 commit。
rebase 命令
来看看你可以使用 git rebase
执行哪些不同的命令:
- 使用
p
或pick
– 使 commit 保持原样 - 使用
r
或reword
– 保留 commit 的内容,但修改 commit 说明 - 使用
e
或edit
– 保留 commit 的内容,但先不要执行 commit,以便:- 添加新内容或文件
- 删除内容或文件
- 修改即将 commit 的内容
- 使用
s
或squash
– 将此 commit 的更改结合到之前的 commit 中(列表中位于其上面的 commit ) - 使用
f
或fixup
– 将此 commit 的更改结合到前一个 commit 中,但删除提交说明 - 使用
x
或exec
– 运行 shell 命令 - 使用
d
或drop
– 删除 commit
当在你 fork 的项目副本上工作时,初始项目的维护者会继续向他们的项目添加更改。你需要将你的 fork 副本与他们的项目保持同步,以包含他们所做的任何更改。
要将源仓库的更改提取到你在 GitHub 上 fork 的仓库副本,你需要:
- 获得源仓库的可克隆 URL
- 使用
git remote add
命令创建一个新的远程仓库- 使用简写名
upstream
指向源仓库 - 提供源仓库的 URL
- 使用简写名
- 获取新的
upstream
远程仓库 - 将
upstream
的分支合并到本地分支 - 将新更新的本地分支推送到你的
origin
仓库
Pull Request ,CONTRIBUTING.md,Issue,https://opensource.guide/
做出贡献
小结
在开始任何工作之前,确保阅读项目的 CONTRIBUTING.md 文件。
接下来,查看项目的 GitHub 问题
- 查看现有的问题,看是否有哪些内容类似于你想贡献的更改
- 如有必要,创建一个新的 Issue
- 与项目维护者交流你想要做出的更改
当开始开发后,将所有工作 commit 到特性分支上:
- 不要在主分支上工作
- 确保给特性分支赋予一个清晰、描述性的名称
以及编写 commit 的一般最佳实践
- 频繁少量 commit
- 使用清晰、具有描述性的提交说明
- 必要情况下,更新 README 文件
特性分支
组织你想贡献给项目的一系列 commit 或更改的最佳方法,是将它们全部放在一个特性分支上。我说的特性分支是什么意思呢?与主分支不同,主分支是保存整个项目的所有 commit 的默认分支,而特性分支仅保存单个概念或单个更改区域的 commit 。
例如,如果登录某个网站的登录表单有问题,则解决此特定问题的分支名称可以叫做:
login
login-bug
signup-bug
login-form-bug
- 等等。
有很多名称可以用作特性分支的名称。你只需为分支提供一个清晰的描述性名称,以便在列出所有分支时,你可以立即根据名称确定要在分支中做哪些更改。
git shortlog -s -n
git log --author=<>
git log --grep=""
使用 git fetch
而不是 git pull
的一个主要情形是当你的远程分支和本地分支都拥有对方所没有的更改时。在这种情况下,你要获取远程更改,将它们存储到本地分支中,然后手动执行合并。最后,你可以将新的合并 commit 推送会远程仓库。
小结
如果你想在本地仓库中包含远程仓库中的更改,那么你要拉取这些更改。要使用 Git 这样做,你需要使用 git pull
命令。你告诉 Git 你想获取修改的远程仓库的简写名以及包含你需要的更改的分支:
$ git pull origin master
在运行 git pull
时,会发生以下活动:
- 远程分支上的 commit 会被复制到本地仓库
- 本地跟踪分支(
origin/master
)移到指向最新的 commit - 本地跟踪分支(
origin/master
)合并到本地分支(master
)
另外,可以在 GitHub 上手动添加更改(但不建议这样做,所以别这样做)。
当 commit 推送到远程仓库后,日志中将出现远程分支指示符。
小结
远程仓库与你使用的本地仓库一样,只是存储在不同的位置。要管理远程仓库,可使用 git remote
命令:
$ git remote
- 你可以连接到多个不同的远程仓库。
- 简写名是用于指代远程仓库位置的名称。通常该位置为 URL,但也可能是同一台计算机上的文件路径。
git remote add
用于添加到新的远程仓库的连接。git remote -v
用于查看远程仓库与连接之间的详细信息。

reset 小结
总结下,git reset
命令被用来清除 commit:
$ git reset <reference-to-commit>
它可以用来:
- 将 HEAD 和当前分支指针移到引用的 commit
- 使用
--hard
选项清除 commit - 使用
--soft
选项将 commit 的更改移至暂存区 - 使用
--mixed
选项取消暂存已被 commit 的更改
我们通常会用到祖先引用来指代之前的 commit。祖先引用包含:
^
– 表示父 commit~
– 表示第一个父 commit
reset 的选项
我们来看看每个选项。
* 9ec05ca (HEAD -> master) Revert "Set page heading to "Quests & Crusades""
* db7e87a Set page heading to "Quests & Crusades"
* 796ddb0 Merge branch 'heading-update'
使用上述示例仓库,其中 HEAD
指向 9ec05ca
上的 master
,运行 git reset --mixed HEAD^
会把 commit 9ec05ca
中做出的更改移至工作目录中。
运行 git reset --soft HEAD^
会把 commit 9ec05ca
中做出的更改直接移至暂存区。
git reset --hard HEAD^
将清除 commit
9ec05ca
中做出的更改。