收藏

1. Git三大特色之WorkFlow(工作流)
2. 5种 Git workflow 简介
3. 详解git merge 与 git rebase的区别

个人见解

一、基本的Git Workflow

在我们小菜菜的日常使用中，使用更多的workflow是收藏2中说的基本的Git Workflow，使用pull拉取代码，push提交代码，永远都是单分支操作。正常情况下，pull拉取代码，会自动将我们的代码进行merge，但是总会有遇到无法自动合并代码的时候，这时可能会出现以下三种情况：

• 操作不担当，自己的代码丢失
• 操作不当，覆盖掉组员的代码
• 手动合并的代码中，因为带有组员代码，导致组员自己与自己的代码冲突

那正确的操作方法应该是怎么样的呢？
首先我们要达到的目的有以下几个：

• 保证自己的代码不丢失
• 保证不覆盖组员的代码
• 保证不手动merge操作时，提交组员的代码

我遇到冲突时的操作流程

注意事项

• 使用fetch&rebase拉取代码，提交记录清晰，与pull的差别，参照收藏3
• fetch&rebase操作时，workspace中不能有正在修改中的代码，要么commit后执行，要么stash后执行fetch&rebase操作
• 容易冲突的文件，单独提交一个记录，遇到冲突时，可以简化操作
• 尽量多的备份，如果失败了，我们还可以重来
• 不要直接操作远程分支
• 如果要使用rebase操作，保证自己的提交记录，永远处于最后方
• rebase操作时，点击abort，等同于放弃此次rebase操作，恢复到操作前
• skip操作前，如果觉得不保险，可以对分支进行备份后再操作
• reset+ stash操作时，解决冲突

revert + stash操作的基本逻辑

当在倒数第二个版本使用reset “master” to this操作后，最后一个版本的代码，会体现在workspace中，这时使用stash操作，等同于将最后一个版本转移到了stash中，在stash之前，将冲突的内容手动解决，最后在master分支git stash pop重新commit代码，以此解决代码冲突。

简化操作

1. 在备份master分支的操作后，直接将备份分支push到远程仓库
2. 在git管理页面，添加merge request请求，将这个麻烦事，甩给组长