git log统计单个分支提交数应使用git log --oneline --no-merges branch-name | wc -l，因--oneline确保每提交占一行，--no-merges排除merge提交避免虚高，比直接git log branch-name | wc -l更准确可靠。
git log 统计单个分支提交数要加 --oneline 和 --no-merges
直接用 git log branch-name | wc -l 会把 merge 提交、空行、甚至颜色控制字符全算进去，结果虚高。真实有效提交数得过滤掉合并提交和格式干扰。
-
git log --oneline --no-merges branch-name | wc -l是最稳的写法：--oneline压缩每条提交为一行，--no-merges排除 merge 提交（避免把合入别人的改动误算成本分支贡献） - 如果想排除特定作者（比如 CI 自动提交），加
--author="^CI$" --invert-grep - 注意：
git log默认从当前 HEAD 开始查，统计非当前分支时务必显式指定分支名，例如git log --oneline main，否则容易漏统计
批量统计多个分支用 git for-each-ref 配合 git rev-list
git branch 输出带星号和空格，不适合直接管道处理；git for-each-ref 是专为脚本设计的安全接口，能精确拿到所有分支引用。
Git Pushing
下载
使用约定式提交信息暂存、提交和推送git更改。当用户想要提交和推送更改、提到推送到远程、或要求保存并推送工作时触发。也适用于用户说“推送更改”、“提交并推送”、“推送这个”、“推送到github”或类似git工作流程请求时。
- 推荐命令：
git for-each-ref --format='%(refname:short)' refs/heads/ | while read b; do echo "$b $(git rev-list --count --no-merges "$b")"; done | sort -k2 -n
-
git rev-list --count比git log | wc -l更快更可靠，它只计算 commit 对象数量，不解析日志内容 - 如果某分支是空分支（只有初始提交且被重置过），
git rev-list可能报错，加2>/dev/null || echo "0"容错
排除 merge 提交但保留 cherry-pick 的技巧
有些团队用 cherry-pick 合并 hotfix，这类提交应该计入原分支，但默认 --no-merges 不影响 cherry-pick（它不是 merge 类型）。真正要小心的是“伪 merge”——比如 git merge --squash 产生的普通提交，它看起来像普通提交，但实际是合并行为。
- 无法靠 git 内置参数自动识别 squash 合并，只能人工约定提交信息关键词（如
[SQUASH]），再用--grep过滤：git log --oneline --no-merges --grep="\[SQUASH\]" branch-name - 如果项目启用了 merge strategy 记录（如
git config merge.log true），merge 提交的 message 里会有Merge:字样，可用--grep="^Merge:" --invert-grep补充过滤 - 注意：不同 Git 版本对
--grep的正则支持有差异，建议用git --version确认 ≥ 2.19
统计结果不准常见原因：rebase 和 reflog 干扰
rebase 会重写 commit hash，导致同一逻辑提交在不同分支上被视为不同对象；reflog 里的临时记录也可能被误读为分支历史。
- 确保统计前执行
git fetch --all，否则本地分支可能落后远程，漏掉新提交 - 不要用
git log -g（reflog）或git log --all替代分支名，它们包含已删除分支或未 push 提交，数据不可比 - 如果某分支近期被 force-push 过，
git rev-list仍会按当前引用计算，但历史提交已不可达——此时需配合git fsck --unreachable判断是否真丢失
feature/login-v2 和 feature/login-v2-fix 被当成两个独立分支，但业务上属于同一功能迭代。这种场景没法靠命令自动归并，得靠人先整理好分支命名策略。
