1. Git拉取项目的两种方式以及区别
方式
- Http:通过http方式的clone项目,不需要在git上手动绑定ssh,只需要在clone的时候输入账号,密码即可;
- SSH:通过ssh方式clone项目,需要手动绑定ssh密钥
区别
- Http方式适合匿名访问,适合开源项目,可以方便被别人克隆和读取(但没有push权限);
- SSh方式适合内部项目开发,只要配置了SSH key即可自由实现clone和push操作。
2. git rebase和git merge
git rebase和git merge命令处理的是同样的问题,这两个命令都用于把一个分支的变更整合进另一个分支——只不过他们达成同样目的的方式不同。
现在,假设在 master 分支上的新提交与你正在开发的 feature 相关。需要将新提交合并到你的 feature 分支中,你可以有两个选择:merge 或者 rebase。
Merge 方式
最简单的方式是通过以下命令将 master
分支合并到 feature
分支中:
git checkout feature
git merge master
这会在 feature
分支中创建一个新的 merge commit,它将两个分支的历史联系在一起,请看如下所示的分支结构:
使用 merge 是很好的方式,因为它是一种 非破坏性的 操作。现有分支不会以任何方式被更改。这避免了 rebase 操作所产生的潜在缺陷(下面讨论)。
另一方面,这也意味着 feature
分支每次需要合并上游更改时,它都将产生一个额外的合并提交。如果master
提交非常活跃,这可能会严重污染你的 feature 分支历史记录。尽管可以使用高级选项 git log
缓解此问题,但它可能使其他开发人员难以理解项目的历史记录。
Rebase 方式
作为 merge 的替代方法,你可以使用以下命令将 master
分支合并到 feature
分支上:
git checkout feature
git rebase master
这会将整个 feature
分支移动到 master
分支的顶端,从而有效地整合了所有 master
分支上的提交。但是,与 merge 提交方式不同,rebase 通过为原始分支中的每个提交创建全新的 commits 来 重写 项目历史记录。
rebase 的主要好处是可以获得更清晰的项目历史。首先,它消除了 git merge
所需的不必要的合并提交;其次,正如你在上图中所看到的,rebase 会产生完美线性的项目历史记录,你可以在 feature
分支上没有任何分叉的情况下一直追寻到项目的初始提交。这样可以通过命令 git log
,git bisect
和 gitk
更容易导航查看项目。
但是,针对这样的提交历史我们需要权衡其「安全性」和「可追溯性」。如果你不遵循 [Rebase 的黄金法则],重写项目历史记录可能会对你的协作工作流程造成灾难性后果。而且,rebase 会丢失合并提交的上下文, 你也就无法看到上游更改是何时合并到 feature 中的。
对比
建议使用 git rebase。
rebase可以给你提供一套清晰的代码历史。相反的, merge会给你一套乱七八糟的代码历史。当你看到这样的代码历史的时候,我相信你绝对没有心情去研究每一个历史对应的代码。