这是一个创建于 1929 天前的主题，其中的信息可能已经有所发展或是发生改变。
一般你们是根据修改的功能点或者新增的功能点，执行一次提交命令，多次提交.
还是一口气把修改新增的东西全部一起提交，然后 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 （可选）。 |
Select Language