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 中的。