一般你们是根据修改的功能点或者新增的功能点,执行一次提交命令,多次提交.
还是一口气把修改新增的东西全部一起提交,然后 Commit message 写一起 message 里面内容太过累赘有影响吗
1
luozic 2019-08-14 18:22:47 +08:00 via iPhone
按 feature 链接备注也是可以的
|
2
tt67wq 2019-08-14 18:25:42 +08:00 2
|
3
ysc3839 2019-08-14 18:25:59 +08:00 via Android
多次提交
|
4
xiaket 2019-08-14 18:30:35 +08:00
不管怎么样, 都是 git commit -v. 看着 diff 提交, 觉得不合适就放弃
|
5
gamexg 2019-08-14 18:32:23 +08:00 1
多次提交
即使有时候是一次完成很多修改后提交,也是拆分开,分别提交每个功能点。 |
6
ieiayaobb 2019-08-14 18:44:23 +08:00
规范的是需要 squash 一下,变成一个 commit 再 push
|
7
TimePPT 2019-08-14 19:05:18 +08:00 via iPhone
拆分功能点多次提交啊,否则回滚时候能逼死人。
|
9
blindie 2019-08-14 19:16:03 +08:00 1
一是可以的,但是一般来说开发过程是混乱的,相关改动中间会隔几个提交。
二如果 commit 过大,review 是没人会主动看。 message 太多,是肯定不行的。如果有相互依赖,为何不直接写在代码中。如果没有依赖,那应该开多个分支分别开发。 合适的做法是善用 cherry-pick, rebase, commit --amend 整出一个符合逻辑的一到多次 commit。如果 message 能合并成一个,那直觉是考虑该不该合成一个 commit。 重点就是每个 commit 的改动需要内聚。(不管以后是查看历史还是 revert 等等才能发挥出版本管理的优势) |
10
xujif 2019-08-14 20:35:43 +08:00
功能分支多个 commit,或者有些规范会要求一个 commit 不停的 amend。
但是 master 总是 squash 成一个 commit。 |
13
Takamine 2019-08-14 22:04:35 +08:00
自己分支多次提交,最后提交上去的时候是一个 。
|
15
luozic 2019-08-14 23:34:39 +08:00 via iPhone
gitflow 的 commit github 的每次 tag 还有合并策略可以看看
|
16
X3nr8yv6bfvk89um 2019-08-14 23:38:02 +08:00
咦,这么没人提 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
X3nr8yv6bfvk89um 2019-08-14 23:38:26 +08:00
@cocoafinish 这么->怎么
|
18
rbe 2019-08-15 00:02:00 +08:00
自己的分支多次提交,是为了防止有 cherry-pick 和 revert 等的需求
最后 git rebase master -i 来做 squash 提交,精简信息对 master 分支查看历史比较有利 |
19
jinliming2 2019-08-15 01:29:16 +08:00 via iPhone
squash 是不经常用的一个功能,一般只在 master 上用。
通常是在 开发分支上进行团队开发,团队中的每个人又在开发分支上迁出多个功能或修复分支进行开发。功能分支和修复分支完成后合并到开发分支。等到开发分支上面的各个功能都稳定之后,合并至主分支发布版本。其中主分支通常为 master,开发分支为 dev,功能分支和修复分支各自起名字。 一般来说,dev 分支处于开发阶段,代码改动量较大,功能变化较大,所以应该尽可能的保证 commit message 尽可能详细,越细越好,这样也更容易发现问题。而代码一旦合并到 master 分支,就表示功能基本稳定了,要发布版本了,版本都发布出去了,精细的历史信息用处就不太大了,所以在 dev 到 master 的时候可以只在 master 上保留关键的信息,其他信息就不用合到 master 了,保持主分支的干爽。 所以 squash 很少用,日常开发基本直接 commit,amend 是在确实应该合并的时候用的。 |
20
Rwing 2019-08-15 08:28:34 +08:00
@cocoafinish gitflow 很好,但是不是楼主问的问题。。。。。
|
21
wleexi 2019-08-15 09:19:01 +08:00
先人任务分解。每做完一个做一个 commit。然后合并 commit 后 push
|
22
Aresxue 2019-08-15 09:25:17 +08:00
从 master 拉测试分支,再从测试拉开发分支,再从开发分支拉取功能点分支,尽量一个功能点一个分支,多个有关联的功能点可以考虑放在一个分支,然后开发时尽可能拆分细致点提交,最后统一合到开发分支上。
|
23
X3nr8yv6bfvk89um 2019-08-15 09:42:03 +08:00
@Rwing 我是想题主的主要问题是 纠结如果颗粒化的 Commit 会导致分支被拉长,但是一口气把修改新增的东西全部一起提交,Commit message 里面内容又太过累赘。我觉得使用 Git Flow 可以把在 Dev 分支上颗粒化的提交,到了一定的阶段合并回主分支打 tag,保证主分支的清爽就可以了。
当然也可能是我过分解读了题主的意思。。。 |
24
Takamine 2019-08-15 10:03:22 +08:00 via Android
@Xbluer 嗯,每个人自己的分支开发自己的模块,merge 到公共开发分支,然后再 merge 到版本发布分支。非临时分支(节日活动等)之后会再 merge 到主分支。
|
25
avenger 2019-08-15 10:51:01 +08:00 via iPhone
merge 的时候怎么合并多次 commit ?
|
26
Youen 2019-08-15 14:33:18 +08:00
随缘.. 写一点测试通过就 commit 一个
规范点的话应该一个 TASK/BUG 一个 commit 吧? |
27
SilentDepth 2019-08-15 15:45:55 +08:00
分支:一个功能点、需求、错误、变更、……
提交:实现一个目标(功能点、需求、……)所需要做的一件事情,可以用一句话较完整地概括的那种。如果一件事情没做完但需要临时切换到其他上下文,提交为 wip,等之后继续工作时 fixup 或者 amend。 |
28
Renco OP 今天学习了 rebase 的相关知识 和 squash 功能的用法,大致了解了 git 谢谢大家
|
29
hantsy 2019-09-15 14:52:08 +08:00
使用 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 (可选)。 |