git拉取项目出现的问题

目录

一、git拉取项目的两种方式和区别

二、git rebase和git merge的区别

2.1、merge

2.1.1、总结

2.2、rebase

三、对于merge和rebase优缺点的总结

---

一、git拉取项目的两种方式和区别

1、方式：

• Http：通过http方式的clone项目，不需要在git上手动绑定ssh，只需要在clone的时候输入账号，密码即可；
• SSH：通过ssh方式clone项目，需要手动绑定ssh密钥

2、区别

• Http方式适合匿名访问，适合开源项目，可以方便被别人克隆和读取(但没有push权限)；
• SSh方式适合内部项目开发，只要配置了SSH key即可自由实现clone和push操作。

二、git rebase和git merge的区别

        git rebase和git merge命令处理的是同样的问题，这两个命令都用于把一个分支的变更整合进另一个分支——只不过他们达成同样目的的方式不同。

         现在，假设在 master 分支上的新提交与你正在开发的 feature 相关。需要将新提交合并到你的 feature 分支中，你可以有两个选择：merge 或者 rebase。

2.1、merge

        merge的原理是找到这两个分支的祖先commit，在两个分支最新的commit进行三方对比合并
        例如上图，共同的祖先commit2,master最新commit6，develop最新commit5，merge会基于2，5，6这三个commit进行对比：

• commit6和commit2对比，如果文件的哈希值不一样，同时commit5和commit2对比，发现一样，说明只有commit6修改了这个文件，这种情况直接合并，不会提示
• commit6和commit2对比，如果文件的哈希值不一样，同时commit5和commit2对比，哈希值不一样，说明两个分支都对同一个文件修改了，则提示冲突，需要我们手动merge

最后合并完后会生成一个新的commit7。

2.1.1、总结

        使用 merge 是很好的方式，因为它是一种 非破坏性的 操作。现有分支不会以任何方式被更改。这避免了 rebase 操作所产生的潜在缺陷（下面讨论）。

        另一方面，这也意味着 develop 分支每次需要合并上游更改时，它都将产生一个额外的合并提交。如果master 提交非常活跃，这可能会严重污染你的 develop 分支历史记录。尽管可以使用高级选项 git log 缓解此问题，但它可能使其他开发人员难以理解项目的历史记录。

2.2、rebase

        这会将整个 develop 分支移动到 master 分支的前端，从而有效地整合了所有 master 分支上的提交。但是，与 merge 提交方式不同，rebase 通过为原始分支中的每个提交创建全新的 commits 来 重写 项目历史记录。

        rebase 的主要好处是可以获得更清晰的项目历史。首先，它消除了 git merge 所需的不必要的合并提交；其次，正如你在上图中所看到的，rebase 会产生完美线性的项目历史记录，你可以在 develop分支上没有任何分叉的情况下一直追寻到项目的初始提交。这样可以通过命令 git log，git bisect 和 gitk 更容易导航查看项目。

        但是，针对这样的提交历史我们需要权衡其「安全性」和「可追溯性」。如果你不遵循 [Rebase 的黄金法则]，重写项目历史记录可能会对你的协作工作流程造成灾难性后果。而且，rebase 会丢失合并提交的上下文， 你也就无法看到上游更改是何时合并到 develop中的。

三、对于merge和rebase优缺点的总结

• rebase：合并后分支图谱好看，一条线，但合并过程中出现冲突的话，比较麻烦（rebase过程中，一个commit出现冲突，下一个commit也极有可能出现冲突，一次rebase可能要解决多次冲突）；
• merge：合并后分支图谱不好看，一堆线交错，但合并有冲突的话，只要解一次就行了；
• 一般的做法，如果合并分支的共同祖先分支相差一两个或两三个commit的话，就用rebase，毕竟rebase合并后好看，分支图谱明确，如果和共同祖先分支相差很多个commit，说明rebase有可能出现多次冲突，合并会很麻烦，这时候就用merge