GIT,可以参数这篇，需要加以理解，文字比较冗余，还请见谅

git的使用步骤一定要记住了；

清除gi他凭证命令：

这样做的好处是，当你在dev-feature开发任务时候，临时接到一个命令，说线上有bug，

那么就可以直接从master分支中在新建一个dev-feature2出来改写你的代码，

这时候你的 dev-feature 正在写新功能，它急需那个 Bug 修复的补丁。你有两种合并方式：

方案 A：直接把 master 合进 dev-feature（最推荐，最稳）

这是最正规的操作。因为 master 刚刚拿到了 dev-feature2 的成果，它现在是最正确的基准。

操作：切换到 dev-feature 分支，点 IDEA 里的 Merge 'master' into 'dev-feature'。
好处：你的开发分支立刻拿到了 Bug 补丁。如果 Bug 修复的地方正好和你正在写的代码有冲突，IDEA 会提醒你，你现在顺手就把冲突解了，不用等到最后上线才痛苦。

方案 B：直接把 dev-feature2 合进 dev-feature

当你准备把 dev-feature 合并到 dev 时，为了保证万无一失，老司机通常会连点三次：

第一步（对齐爷爷） ：切换到 dev，执行 Merge 'master' into 'dev'。
- 作用：确保 dev 拿到了最新的线上补丁，跟爷爷同步了。就是刚才的那个dev-feature2补丁
第二步（预演合并） ：切换到 dev-feature，执行 Merge 'dev' into 'dev-feature'。
- 作用：在你自己的分支上先看看，加上了 dev 的最新代码后，会不会跟你的新功能起冲突。有问题在自己分支解决，别弄乱了公共的 dev。
第三步（正式上交） ：切换回 dev，执行 Merge 'dev-feature' into 'dev'。
- 作用：这时候合并是"顺水推舟"，因为你在第二步已经解决过冲突了。

dev-feature2改动代码，提交合并到master上，

开发过程中；

本地的dev-feature代码改了，然后要合并到dev之前，需要commit一下，才可以合并到dev

然后再继续进行提交到远程的dev;

dev分支，作为基点，不进行代码的修改和更新，只是作为本地和远程仓库之间通讯的桥梁作用

本地保持一个干净的 dev 用来同步远程，是一个极好的习惯。

每次提交dev之前，需要先更新代码，解决冲突，在提交，push,

这样就可以解决大部分的代码冲突问题了；

若果说凭证问题；

可以先在window下：

清除也是可以

当你准备把 dev-feature 合并到 dev 时，为了保证万无一失，老司机通常会连点三次：

• 作用：确保 dev 拿到了最新的线上补丁，跟爷爷同步了。

• 作用：在你自己的分支上先看看，加上了 dev 的最新代码后，会不会跟你的新功能起冲突。有问题在自己分支解决，别弄乱了公共的 dev。

• 作用：这时候合并是"顺水推舟"，因为你在第二步已经解决过冲突了。

💡 总结一下：

• Merge 'master' into 'dev'：是向下兼容。让中间分支（dev）跟上最高准则（master）。

• Merge 'dev-feature' into 'dev'：是向上贡献。让你的成果进入公共区域。