作者Samuel (I've got it!)
看板Soft_Job
标题[请益] git 操作问题
时间Wed Mar 9 14:55:14 2016
问题是这样的
专案在开发可能会因为开发某 feature
从 master 切 branch 出来
如果需要 master 上面的 update
如果是自己的话就还好 可以自己在 local git rebase
但是如果多人开发同一个 feature
会交互的 commit code 到 remote 上
在需要 update master code 的时候
这样的话就不能作 rebase
通常的作法会是 cherry-pick
恶心一点的话就会直接把 master merge into feature
会造成 git merge graph 相当的可怕
问题说到这边
也许有人会说
「为什麽要从 master merge into feature？，这样不对啊」
「可能是 feature 切的不够细」
「可能是 commit 颗粒掌握不对」
...
会有一些类似这种 operation 上面的认知的问题
说这麽多是想请问各位大大
以 git remote rebase(误) 作为纠结的起点
各位有什麽解法吗？！
或是有什麽 best practice 可以躲过这些问题？
我想要做到的就是「不影响他人的」remote rebase 作法 XD
（当然 remote 是无法 rebase 我知道 QQ）
各位有什麽建议吗？
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.163.170.73
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1457506517.A.0AA.html
1F：→ abola921: 像github一样 fork 然後pull 03/09 15:06
2F：推 spjay1: git flow? master 不上commit? 03/09 15:23
3F：→ Samuel: 一楼的意思是，相当於在多一层（forked repo）把 feautre 03/09 15:34
4F：→ Samuel: branch 作的事情，放在forked repo 作，最後PR回去吗？ 03/09 15:34
5F：→ Samuel: master上commit可能是其他feature completed, merged in 03/09 15:36
6F：→ JingJing00: feature/boo_v1 feature/boo_v2 03/09 15:40
7F：→ Samuel: 楼上的意思是在 branch 内分版号盖资料夹吗？ 03/09 15:59
8F：推 dojay: feature2 从 feature1 分支出来，两个相 03/09 16:20
9F：→ dojay: 互 merge，最後再由 feature1 merge 回 m 03/09 16:20
10F：→ dojay: aster 03/09 16:20
11F：→ Samuel: 这样作法让我有点混淆，这样feature2其实不是feature但是 03/09 16:36
12F：→ Samuel: 却有了branch 还且还是在feature1上，而branch原因不明 03/09 16:36
13F：→ Samuel: 在图上有会看到feature有从master来的线, 这样很乱 03/09 16:37
14F：→ Samuel: 还是说这些动作是在 local 作，所以feature2最终只会变成 03/09 16:38
15F：→ Samuel: feature1的空降commit(相当於处理完merge master的diff) 03/09 16:39
16F：→ Samuel: 是这样的意思吗？ 03/09 16:39
17F：→ Samuel: 这样的话假设是以squash方式rebase(from f2 to f1) 03/09 16:40
18F：→ Samuel: 最终feature1回到master有没有办法处理这个commit? 03/09 16:41
19F：→ Samuel: 已经作过的commit会不会在重新算一次？ 03/09 16:41
20F：→ Samuel: 如果不是squash的话那势必与master之间的线就变成蜘蛛网了 03/09 16:42
22F：→ abola921: fork 像branch 但实际上完全是独立的 repo 03/09 18:09
23F：→ abola921: 在自己的repo中改完後，到原project 提出pull request 03/09 18:10
24F：→ abola921: 大家玩法不尽相同，我是没有再用branch了 03/09 18:14
25F：推 popcorny: merge master into feature没有什麽不好啊.. 03/09 18:32
26F：→ popcorny: 如果你的feature branch控制得好的话.(local到remote 03/09 18:32
27F：→ popcorny: 都有rebase.. 那最後graph也只有master到feature的一 03/09 18:33
28F：→ popcorny: 条线而已.. 不会太乱啦 03/09 18:33
29F：→ popcorny: 当然通常feature也不会拉太长时间 03/09 18:33
30F：→ popcorny: 两周差不多可以merge/rebase回master了.. 03/09 18:34
31F：→ popcorny: 就不会有需要master到feature这段了 03/09 18:34
32F：→ legnaleurc: 多人开发同一个 branch 本来就是会互相 merge 03/09 20:55
33F：→ legnaleurc: 只在意 merge graph 好不好看你就不用做事了 03/09 20:55
34F：→ Samuel: 感觉用 forked_repo + PR 比较容易达成 03/09 21:48
35F：→ Samuel: 这其实是实行 git flow 所注意到的缺点 03/09 21:49
36F：→ Samuel: git flow 上所建议的 branch 有其意义, 他可以在 rollback 03/09 21:49
37F：→ Samuel: 更能清楚的带出 source 可以修改的方向 03/09 21:50
38F：→ Samuel: 或是要切换版本间开发有更大的弹性 03/09 21:50
39F：→ Samuel: 但「事实上」用到这些「弹性」的时机很少，甚至可以说是假 03/09 21:51
40F：→ Samuel: 议题也无妨,实务上当然是怎麽merge都可以, 甚至anti-flow 03/09 21:52
41F：→ Samuel: 直接使用master也是一种玩法! 03/09 21:53
42F：→ Samuel: 我所想要探知的是以git flow 玩feature branch 怎麽解这些 03/09 21:55
43F：→ Samuel: 问题 03/09 21:55
44F：推 abc0922001: 要merge graph一条线要干嘛？用到SVN吗 03/09 22:23
45F：推 abc0922001: 大家都开个新branch，统一由一个人合到master 03/09 22:30
47F：→ Samuel: 我原本也不在意，但在回头看到1920解析度无法装下git log 03/09 23:02
48F：→ Samuel: --graph 的 branch line, 切确的发现branch merge已失去意 03/09 23:03
49F：→ Samuel: 义 03/09 23:03
50F：→ Samuel: (确认我们的开发人数+branch并没有这麽大的规模^^") 03/09 23:06
51F：→ Samuel: 这种严谨 merge team 似乎是个作法，但就要看规模了 03/09 23:08
52F：推 GALINE: 我的建议是: 1)研究 git 的 pretty 设定 2) 装tig... 03/09 23:55
53F：→ GALINE: 如果 tig 下去图还是很难读，那感觉开发规模也不小了 03/09 23:56
54F：→ GALINE: 若功能branch只有一个人用，时常rb到master上然後force 03/09 23:58
55F：→ GALINE: push 也是解法，不过这最好搭配对 master 的保护机制，像 03/09 23:58
56F：→ GALINE: 是 gitlab 的 protected branch 03/09 23:59
57F：→ GALINE: 切 branch 除了考古方便以外，一个人同时做两三个功能时 03/10 00:01
58F：→ GALINE: 也相对不容易搞混自己做到哪里，可以整个环境抽换掉 03/10 00:01
59F：→ GALINE: 或是像是一边开发新功能一边修旧bug之类的.... 03/10 00:03
60F：推 GALINE: 另外是多人合作时，送pull request就是该code review了... 03/10 00:05
61F：→ GALINE: 这时候进 master 的意义就变成"code 有被审过" 03/10 00:06
62F：→ Samuel: 感谢建议! 我会来试试看 03/18 21:32