震惊！我发现新来的组长太水了，连合并代码解决冲突都不会，竟然直接丢弃～
老鬼约 5 分钟你们知道的，做后端的，尤其是涉及到Java的项目，通常都需要管理大量的代码分支。
我们组长作为一个资深的Java后端工程师，平时项目架构搭建、服务器管理一手抓，感觉工作能力那是相当的强。刚加入团队时，我对他充满敬意，觉得他就是那种“从不犯错”的技术大神。
不过，直到有一次我发现了一个有趣的事情，我才意识到，有时候“大神”也会有“bug”…
事情的起因
那天，我在和组长一起做代码合并。正常来说，在团队合作中，我们需要定期合并不同分支的代码，确保代码同步和避免冲突。
一般来说，我的工具是IDEA自带的Git，它对Git的集成非常好，简直是拉取、推送、查看变更一键搞定。虽然偶尔会遇到冲突，但IDEA会通过图形界面引导你一步步解决，非常直观。
然而，那天我发现，组长居然用的是SourceTree来管理代码。
乍一看，这个工具不算难用，至少对初学者来说，功能也是挺全的。可是，等我仔细看，他解决代码冲突的方式让我有点懵了。你们知道，Git合并冲突是开发过程中最让人头疼的部分之一，正确的解决方式不仅能保证代码的正确性，还能减少后续的Bug。
而我们组长，似乎对如何正确合并冲突并不熟悉。每次遇到冲突，他都会直接选择“接受当前分支”或者“接受另一分支”的代码，然后把丢失的代码手动补上。听到这个，我顿时觉得有点不太对劲，毕竟Git提供了丰富的工具来帮助我们解决冲突，这种直接丢弃的方式简直让人“心疼”了。
错误的解决方式
让我们看看组长的操作：
选择丢弃一方的代码：组长在遇到冲突时，往往选择“接受当前分支的代码”或者“接受另一分支的代码”，然后忽略冲突的部分。这种方式看起来简单快捷，但根本无法保证代码的完整性。因为很多时候，丢弃的代码可能是非常重要的逻辑部分，导致功能缺失或Bug出现。
手动补充丢失的代码：组长在选择丢弃某些代码后，会手动补充丢失的部分，这听起来像是临时解决方案，但这种方式不仅麻烦，还容易出错。毕竟手动补充代码存在很大的风险，尤其是代码变动很大时，可能会遗漏细节，甚至破坏原本的代码逻辑。
这种方式，显然不是Git合并冲突的最佳实践。更麻烦的是，手动补充代码可能导致“重复”或者“冗余”的代码，这对于后续的代码维护非常不友好。
正确的解决方法
那么，正确的Git冲突解决方法是什么呢？其实，Git本身提供了强大的工具来帮助我们解决冲突。
正确的做法是：在合并冲突时，尽量手动选择需要保留的部分，或通过工具查看差异，并保留正确的代码。
步骤一：了解Git的合并冲突
Git合并冲突通常发生在以下情况：
两个分支在同一个文件、同一部分的代码做了不同的修改。 Git无法自动决定保留哪部分代码，因此会标记为冲突。
比如，我们有两个分支：feature-x 和 develop，都修改了UserService.java中的同一段代码。Git无法自动决定使用哪一边的更改，因此会标记为冲突。
步骤二：使用IDEA自带工具解决冲突
首先，在IDEA中，Git会在你合并代码时，自动检测到冲突并标记出冲突的文件。你可以右键点击文件，选择“Git” -> “Resolve Conflicts”。
然后，IDEA会用图形界面展示冲突的部分，并分成三列：
左侧：当前分支的代码。 右侧：合并进来的代码。 中间：合并后的代码（通常显示为冲突的标记）。
这时，你可以通过简单的点击来选择“接受左边的代码”或者“接受右边的代码”。如果这两者的修改都有价值，你也可以手动修改合并后的代码，并保存。
步骤三：手动解决复杂冲突
对于一些复杂的冲突，可能需要我们仔细查看代码的具体差异，进行手动选择。此时，可以使用命令行工具或者Git自带的冲突解决工具：
# 使用命令行查看冲突
git status
Git会告诉你有哪些文件发生了冲突，并标记为“Unmerged”。你可以使用以下命令来标记冲突已解决：
# 标记文件为已解决
git add <filename># 提交合并
git commit
步骤四：避免手动补充代码
如果我们发现手动补充代码的方式过于麻烦且容易出错，我们可以尝试用更高效的方式解决冲突。比如，借助Git的“merge tool”或者图形化工具（如SourceTree本身的冲突解决功能），可以更方便地对冲突进行比对，自动选择合适的部分进行合并。
在IDEA中，还可以通过“Git -> Show History”来查看代码历史，帮助我们理解冲突的根源，做出更合适的决策。
为什么直接丢弃不行？
直接丢弃冲突的代码是一种非常危险的操作。虽然在短期内可以避免复杂的操作，但长期来看，容易引入未知的Bug。尤其是在团队合作中，不同的开发者可能对同一段代码有不同的理解，丢弃代码就等于放弃了这些贡献，可能会导致功能缺失，甚至系统崩溃。
更重要的是，丢弃代码后，往往无法知道丢弃部分是否包含了重要的逻辑或修复的Bug。手动补充代码的做法，虽然看似可以恢复丢失的部分，但往往因为没有系统的追溯，导致补充的代码不准确或不完整。
小结
经过这次事件，我学到了很多，也意识到工具和方法的选择对开发效率和代码质量的影响。作为程序员，尽量避免简单粗暴的操作，特别是在涉及代码合并和冲突解决时。
Git是个强大的工具，它提供了丰富的合并冲突解决功能，能够有效避免冲突带来的麻烦。如果你也遇到类似的问题，记得好好利用工具，仔细选择合适的合并策略，而不是简单地丢弃代码，手动补充。
-END-
以上，就是今天的分享了，看完文章记得右下角给何老师点赞，也欢迎在评论区写下你的留言。