首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
git
Pro Git
Atlassian Git Tutorial
Pro Git 简体中文翻译
GitX
V2EX  ›  git

问问 V 友们 Git 提交的规范

  •  
  •   Renco · 68 天前 · 3343 次点击
    这是一个创建于 68 天前的主题,其中的信息可能已经有所发展或是发生改变。

    一般你们是根据修改的功能点或者新增的功能点,执行一次提交命令,多次提交.

    还是一口气把修改新增的东西全部一起提交,然后 Commit message 写一起 message 里面内容太过累赘有影响吗

    29 回复  |  直到 2019-09-15 14:52:08 +08:00
        1
    luozic   68 天前 via iPhone
    按 feature 链接备注也是可以的
        2
    tt67wq   68 天前   ♥ 1
        3
    ysc3839   68 天前 via Android
    多次提交
        4
    xiaket   68 天前
    不管怎么样, 都是 git commit -v. 看着 diff 提交, 觉得不合适就放弃
        5
    gamexg   68 天前   ♥ 1
    多次提交

    即使有时候是一次完成很多修改后提交,也是拆分开,分别提交每个功能点。
        6
    ieiayaobb   68 天前
    规范的是需要 squash 一下,变成一个 commit 再 push
        7
    TimePPT   68 天前 via iPhone
    拆分功能点多次提交啊,否则回滚时候能逼死人。
        8
    Renco   68 天前
    @ieiayaobb squash 一下,变成一个 commit 那 squash 之前的 commit 信息还能看到吗
        9
    blindie   68 天前   ♥ 1
    一是可以的,但是一般来说开发过程是混乱的,相关改动中间会隔几个提交。
    二如果 commit 过大,review 是没人会主动看。
    message 太多,是肯定不行的。如果有相互依赖,为何不直接写在代码中。如果没有依赖,那应该开多个分支分别开发。
    合适的做法是善用 cherry-pick, rebase, commit --amend 整出一个符合逻辑的一到多次 commit。如果 message 能合并成一个,那直觉是考虑该不该合成一个 commit。
    重点就是每个 commit 的改动需要内聚。(不管以后是查看历史还是 revert 等等才能发挥出版本管理的优势)
        10
    xujif   68 天前
    功能分支多个 commit,或者有些规范会要求一个 commit 不停的 amend。
    但是 master 总是 squash 成一个 commit。
        11
    Renco   68 天前
    @xujif 了解了,也是,每次合并分支的时候 会有一大堆 commit 的信息,master 分支突然就被拉的很长
        12
    wispx   68 天前
    @tt67wq #2 "Copy-paste to fix previous copy-paste", 这个秀
        13
    Takamine   68 天前
    自己分支多次提交,最后提交上去的时候是一个 。
        14
    Xbluer   68 天前
    @Takamine #13 建一个私有分支修改代码,然后 merge 回公共分支?
        15
    luozic   68 天前 via iPhone
    gitflow 的 commit github 的每次 tag 还有合并策略可以看看
        16
    cocoafinish   68 天前
    咦,这么没人提 Git Flow

    “主分支只用来分布重大版本,日常开发应该在另一条分支上完成。我们把开发用的分支,叫做 Develop。

    这个分支可以用来生成代码的最新隔夜版本( nightly )。如果想正式对外发布,就在 Master 分支上,对 Develop 分支进行"合并"( merge )。”

    摘抄自 阮一峰老师的博客: http://www.ruanyifeng.com/blog/2012/07/git.html



    我的理解是 Develop 分支可以按功能点多次提交,然后到一定阶段 Merge 回 Master 分支。
    这样 Develop 有详细的 Commit 记录,同时也保证了主分支的清爽。
    不知道有没有理解错~

    有用的链接
    https://nvie.com/posts/a-successful-git-branching-model/

    翻译:
    https://blog.devorz.com/2019/04/18/A-successful-Git-branching-model/
        17
    cocoafinish   68 天前
    @cocoafinish 这么->怎么
        18
    rbe   68 天前
    自己的分支多次提交,是为了防止有 cherry-pick 和 revert 等的需求
    最后 git rebase master -i 来做 squash 提交,精简信息对 master 分支查看历史比较有利
        19
    jinliming2   68 天前 via iPhone
    squash 是不经常用的一个功能,一般只在 master 上用。
    通常是在 开发分支上进行团队开发,团队中的每个人又在开发分支上迁出多个功能或修复分支进行开发。功能分支和修复分支完成后合并到开发分支。等到开发分支上面的各个功能都稳定之后,合并至主分支发布版本。其中主分支通常为 master,开发分支为 dev,功能分支和修复分支各自起名字。
    一般来说,dev 分支处于开发阶段,代码改动量较大,功能变化较大,所以应该尽可能的保证 commit message 尽可能详细,越细越好,这样也更容易发现问题。而代码一旦合并到 master 分支,就表示功能基本稳定了,要发布版本了,版本都发布出去了,精细的历史信息用处就不太大了,所以在 dev 到 master 的时候可以只在 master 上保留关键的信息,其他信息就不用合到 master 了,保持主分支的干爽。
    所以 squash 很少用,日常开发基本直接 commit,amend 是在确实应该合并的时候用的。
        20
    Rwing   68 天前
    @cocoafinish gitflow 很好,但是不是楼主问的问题。。。。。
        21
    wleexi   68 天前
    先人任务分解。每做完一个做一个 commit。然后合并 commit 后 push
        22
    Aresxue   67 天前
    从 master 拉测试分支,再从测试拉开发分支,再从开发分支拉取功能点分支,尽量一个功能点一个分支,多个有关联的功能点可以考虑放在一个分支,然后开发时尽可能拆分细致点提交,最后统一合到开发分支上。
        23
    cocoafinish   67 天前
    @Rwing 我是想题主的主要问题是 纠结如果颗粒化的 Commit 会导致分支被拉长,但是一口气把修改新增的东西全部一起提交,Commit message 里面内容又太过累赘。我觉得使用 Git Flow 可以把在 Dev 分支上颗粒化的提交,到了一定的阶段合并回主分支打 tag,保证主分支的清爽就可以了。
    当然也可能是我过分解读了题主的意思。。。
        24
    Takamine   67 天前 via Android
    @Xbluer 嗯,每个人自己的分支开发自己的模块,merge 到公共开发分支,然后再 merge 到版本发布分支。非临时分支(节日活动等)之后会再 merge 到主分支。
        25
    avenger   67 天前 via iPhone
    merge 的时候怎么合并多次 commit ?
        26
    Youen   67 天前
    随缘.. 写一点测试通过就 commit 一个

    规范点的话应该一个 TASK/BUG 一个 commit 吧?
        27
    SilentDepth   67 天前
    分支:一个功能点、需求、错误、变更、……
    提交:实现一个目标(功能点、需求、……)所需要做的一件事情,可以用一句话较完整地概括的那种。如果一件事情没做完但需要临时切换到其他上下文,提交为 wip,等之后继续工作时 fixup 或者 amend。
        28
    Renco   67 天前
    今天学习了 rebase 的相关知识 和 squash 功能的用法,大致了解了 git 谢谢大家
        29
    hantsy   36 天前
    使用 Github Flow 或者 Git Flow。个人比较偏向 Github Flow。

    首先一个任务如果复杂的话可以定义成一个 Checklist,Github Issues 支持 Checkbox 形式。

    1. 每个任务一个分支(可以先 Fork,再创建 Branch ),此时可以建 PR (每次提交 PUSH 后运行 CI 测试)。

    2. 每完成一个 item, 可以 Commit 一次。**保证每次提交的代码是可以通过 CI 测试,是一个 Workable 的单元**,不然根本不可能实现自动部署。如果发现什么遗漏,回归测试错误,立即修正,可以使用 Amend 合并到上一次提交。

    3. 所在的 Checklist 完成,关闭 Issue, 直接写在 Commit Message,如:fixes #123。创建 PR (也可以提前建)。

    4. 启动 Peer Code Review (如果 PR 提前建,可提前)。 根据意见修改代码等,直到所有的考虑已经实现,所有的测试都通过。

    5. 合并到 Master,触发自动部署 Pipeline (可选)。
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4076 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 31ms · UTC 01:25 · PVG 09:25 · LAX 18:25 · JFK 21:25
    ♥ Do have faith in what you're doing.