代码同步

Fetch

fetch 是最简单的操作,它将远程仓库的代码、 分支和 tag 都下载到本地。有些 GUI 工具会定期自动执行 fetch

注意,如果仅仅是 fetch 代码,并不会改变本地的代码,仅仅是预先下载了远程仓库的变动而已。直到我们进行 rebasemergecheckoutreset 等操作时,才会改动本地代码。

Rebase or Merge

rebase 和 merge 分别是合并代码的两种操作。

rebase 是变基,也就是改变某次提交的父提交。假设当前处于分支 branch_a 并执行:

git rebase branch_b

本质上是找到 branch_abranch_b的公共祖先,然后将 branch_a 到这个公共祖先中的每一次提交,依次变基到 branch_b 上。

同样是上面的情况,使用merge

git merge branch_a

则会将 branch_a 到公共祖先之间的提交压缩成一次新的提交,附加在 branch_b 的后面。

关于选择 merge 还是 rebase,一般没有明确的要求。前者忠实的保留了每次提交的真实情况,但是多人开发时频繁 merge 容易导致时间线爆炸,影响阅读。rebase 的优点在于它创造出更加优雅的提交记录,缺点则是破坏了真实的提交记录。

但假设我们有一个主分支 dev,还有一个开发分支 feature ,两者都提交了上百次代码,现在想把开发分支合入主分支,那么大概率应该使用 merge。一方面这样的合并次数很少,不会造成时间线爆炸,反倒是真实的保留了 feature 分支的提交记录,最重要的是如此庞大的两个分支合并一定会带来大量冲突。 merge 会自动把所有提交压缩成一个,只要解决一次冲突就行,但 rebase 的次数将会达到上百次,会出现大量不必要的冲突。

举个很简单的例子,假设提交 ab 是两个互逆的操作,那么在 merge 就互相抵消了,但如果使用 rebase,就需要解决两次冲突。

但如果只是想从远程仓库获取代码,并且更新本地的代码,此时就更推荐 rebase 了,我配置了快捷键 gsfrs,它的完整定义是:

alias gsfrs='git stash;git fetch;git rebase;git stash pop;'

交互式 Rebase

对于已经存在但还没有推送到远程的提交记录,我们可以使用 rebase -i 去编辑他们。假设我们想修改最近三次提交,可以输入 gri head~3,它是完整写法是:

git rebase -i head~3

这个命令会展示出最近的三次提交,最老的提交在最上面,最新的提交在最下面,这是因为 git 会按照从旧到新的顺序编辑这些提交。展示的格式如下:

pick commit_id commit_message

我们可以随意调整这三行的顺序,相当于改变提交的顺序。如果把单词 pick 改成 rewordr,就可以修改提交记录。

git 还支持以下关键字:

  1. edite:编辑此次提交
  2. dropd:删除此次提交
  3. fixf:将此次提交与上次提交合并

Pull

pull 可以理解为一个语法糖,因为它等价于 fetch + merge,前文已经说过日常开发时并不推荐使用 merge,只有在偶尔分支合并时才应该使用,因此 pull 也应该慎用。

Commit

前文说过通过交互式 rebase 可以修改历史提交记录,但如果只想修改上一次提交的信息,可以使用更简单的 gca 命令,它的完整写法是:

git commit --amend

然后编辑 commit_message 并退出即可。

我们都知道提交代码前,需要先将改动的文件暂存,然后再提交。但如果我们想提交所有未暂存的文件,其实还有更快速的方法:gcam,它的完整写法是:

git commit --all -m
# 实际上等价于
git add . && git commit -m

results matching ""

    No results matching ""