Git坑爹使用方式指南

目录




一、前言

这里是自己或者他人遇到的一些不好的Git习惯的总结，有的是新人工作习惯不好，有的是因为对git原理不熟悉，有的是因为对IDE集成的git功能不熟悉等等，这里总结一些场景，希望能帮助到别人



二、Git独奏篇

1.commit频率太少或者太频繁

原因

  • commit太少：一旦出现一些比如机器问题或者合并，导致的本地修改丢失

  • commit太多：另一种极端，虽然代码不会丢了，但是带来了其他问题

    1. 协作时，涉及到合并，或者你写的代码被他人依赖时，别人无法直接的简单通过git cherry-pick摘取需要的部分（需要摘取很多，或者通过git merge 或者通过copy）
    2. git log信息爆炸，可读性变差

正确做法

  • 一个相对独立的小功能、或者一组函数完成、或者一个类实现时，提交一次

2.commit信息太少

原因

  • git log可读性极差

错误示范

  • git commit -m "add"
  • git commit -m "temp"

正确做法

  • 至少说明本次提交的目的或者其他简要信息

    • git commit -m "fix sort problem"
    • git commit -m "add float utils and unittest"



3.提交二进制文件或者log日志文件等无关信息

原因

  • 二进制文件可以通过代码生成，log文件无意义
  • 二进制文件还会使git拉取代码变慢

正确做法

  1. 通过.gitignore忽略
    Git文件忽略用法
  2. 通过钩子脚本，禁止大文件提交
    Git钩子用法
    Git禁止提交大文件



三、Git协作

1.直接merge 被依赖代码的分支

原因

  • 协作开发时，A同事，虽有依赖B同事负责的特性，但是不一定同时上线，A直接merge B的分支，会使A的开发分支被污染，上线时也可能带上其他逻辑

    可能你会说，可以在上线前删除或者注释A的部分代码，不过这也不是一个好的做法，后面的例子会说明

正确做法

  • 如果出现代码依赖，最好的做法是通过git cherry-pick对方代码中你需要的部分

2.直接文件copy 被依赖代码的分支

原因

  • 只复制文件，虽然A避免了携带B的其他特性，但是复制文件是会修改此文件的modify_time，导致此分支文件被当做全新的文件，极易覆盖以后B分支这几个文件修改

正确做法

  • 如果出现代码依赖，最好的做法是通过git cherry-pick对方代码中你需要的部分

3.修复问题时，直接在公有分支修改

Git Flow 前置知识
原因

  • 比如测试分支test_xxx0810汇聚了众多待测试feature分支的特性，有bug发现后，直接在test分支修改后，后面feature分支合并时，会覆盖之前test_xxx0810的修改

正确做法

  • 自己特性的代码，修复逻辑也在自己的特性分支，修复验证后，再合并到test分支，不要直接修改test分支代码



四、其他

大多数的git误操作，来源于git不熟悉，或者部分git flow流程不了解，附上学习资料供参考
Git权威指南

如果有其他的工作中常见误操作场景，欢迎评论交流

posted @ 2020-09-05 18:40  Reazon  阅读(106)  评论(0)    收藏  举报