# 在自己的分支feature上开发，从master上拉最新改动,
# 避免自己的分支落后master
git checkout feature
git rebase master
1. 合并方式
- merge：合并操作。它会取出一个公共的祖先节点，然后尝试将两个分支从该节点开始发生的所有变化都合并到一起，最终生成一个新的节点（合并提交）。这个新节点会包含两个分支的所有修改。
- rebase：变基操作。它会先将当前分支上的所有提交临时保存，然后将当前分支更新到master的最新状态，接着将之前保存的提交逐个应用到master的最新状态上，形成一个新的线性提交历史。
2. 提交历史
- merge：会保留完整的合并历史，每次合并都会生成一个新的合并提交，这使得提交历史呈现出分叉的结构。这种方式可以清晰地看到每个分支的修改历史，但也可能导致提交历史变得复杂。
- rebase：会保持一个线性、整洁的提交历史。通过将当前分支的提交“重放”到master的最新状态上，可以使得提交历史看起来像是所有更改都在一个连续的时间线上进行。这种方式使得提交历史更加清晰，易于阅读和维护，但也会改变原有的提交历史。
3. 处理冲突
- merge：在合并过程中，如果发生冲突，Git会提示手动解决冲突，并提交合并后的结果。这可能会导致在合并提交中包含解决冲突的痕迹。
- rebase：在变基过程中，如果发生冲突，Git会停止变基操作，并提示解决冲突。解决冲突后，需要手动继续变基操作。这种方式允许在每个提交上逐个解决冲突，而不是在整个分支上进行冲突解决，这可能使得冲突解决更加清晰和容易。
4. 使用场景
- merge：希望保留完整的合并历史，或者两个分支的历史相对独立，且需要保留各自的提交历史时，可以使用
merge。此外，merge的合并方式更加保守，适合在不确定是否要改写提交历史时使用。
- rebase：当你希望保持一个线性、整洁的提交历史，或者想要将当前分支的提交历史重写为基于另一个分支的最新提交时，可以使用
rebase。这种方式适合在团队协作中，保持提交历史的清晰和一致性。rebase会改变提交历史，因此在使用时需要谨慎，并确保团队成员都了解这一变化。
