如何对git的master和feature分支自动格式化且不引发合并冲突

单次格式化操作步骤（适配你当前的仓库状态） #

你的冲突根源是两个分支分别独立生成格式化提交，没有公共的格式化基准，Git会将双方的格式修改识别为异源冲突。按以下步骤操作可完全规避该问题，无需Rebase Feature分支：

1. 检出两个分支的公共祖先提交

git checkout 6a62db6

2. 运行全仓库代码格式化，生成基准格式化提交

# 按你的规则执行格式化，此处以clang-format为例
clang-format -i *.h *.cpp
git add .
git commit -m "Base clang-format for all branches"

记录本次提交的哈希值，假设为abc123
3. 将基准格式化提交合并到Master分支

git checkout master
git merge abc123 -m "Merge base format config"

如果合并过程中提示冲突，直接对冲突文件执行格式化命令，再提交即可，无需手动处理冲突内容。
4. 用相同逻辑将基准格式化提交合并到Feature分支

git checkout feature
git merge abc123 -m "Merge base format config"

操作完成后两个分支的格式化规则完全同源，后续互相合并不会再触发格式类冲突。

团队常态化配置方案 #

为了避免后续再出现同类格式冲突，可配套以下规则落地：

• 把.clang-format规则文件提交到仓库根目录，所有团队成员共用同一套规则，禁止私自修改本地格式化配置
• 配置Pre-Commit钩子，提交代码前自动格式化当前修改的C/C++文件，钩子示例如下：

#!/bin/sh
FORMAT_FILES=$(git diff --cached --name-only -- '*.cpp' '*.h')
if [ -n "$FORMAT_FILES" ]; then
    clang-format -i $FORMAT_FILES
    git add $FORMAT_FILES
fi
exit 0

• 若后续合并时偶发格式类冲突，直接在冲突文件上跑一遍clang-format即可自动解决纯格式导致的冲突，无需手动修改。

可选极简方案（可接受Rebase的场景） #

如果团队可以接受Rebase操作，可选择历史更整洁的方案：

1. 先在Master分支完成格式化并提交
2. 切换到Feature分支执行Rebase

git checkout feature
git rebase master

3. Rebase过程中遇到冲突时，直接运行clang-format -i 冲突文件，再执行git add 冲突文件 && git rebase --continue即可自动解决格式冲突。

内容的提问来源于stack exchange，提问作者MHebes