推动和改变生活分支的策略是什么？

Question

我想了解在已推送的分支上使用rebase策略是否是保持主日志历史记录清洁的良好解决方案。

情况是我正在开发现有项目的功能，而且我是这个特定功能的唯一开发人员。但是，在准备合并之前，我不想保持本地化。相反，我希望定期推动我的工作以获得反馈，并为我的同事提供灵感。

不幸的是，在开发过程中master也在不断发展。为了避免我的分支偏离主设备太远，我可以决定与主设备merge或rebase。

因为重新定位会重写历史，所以社区（SO）通常会让我这么做。特别是当我已经推动了我的一些工作。尽管有这些建议，我觉得在主人之上重新定位我的工作有时仍然是正确的做法。

让我们想象一下，在rebase和更常见的merge策略两种情况下几周后我的工作：

Solution with merge                Solution with rebase

G    master origin/master              n feature origin/feature
| e  feature origin/feature            m
F/|                                    l
E |                                    k
| d                                   /
| c                                  G master origin/master
D/|                                  F
C |                                  E
| b                                  D
| a                                  C
B/                                   B
A                                    A

当最后的merge到来时，将我的开发的完整历史记录拖回主页将导致复杂的日志，有时难以阅读。

rebase解决方案可以轻松实现快速合并，最终实现更清晰的日志。

H    master/origin/master
G \    
| e                                  n master origin/master
F/|                                  m
E |                                  l
| d                                  k 
| c                                  G 
D/|                                  F
C |                                  E
| b                                  D
| a                                  C
B/                                   B
A                                    A

然而，这个解决方案并非没有陷阱。如果我不想被任何人憎恨，其他开发者必须遵守一些规则。

1. 名为feature/<name>-u的分支（对于不稳定）有时可能会在主人的顶部重新定位
2. 在这些分支机构上，不会发布正式版本
3. 我绝不能承诺在外国专题分支的顶部

我还应该担心什么？

当然还有第三个解决方案是squash该功能作为master上的一个提交，可以替代此工作流程。这有助于在主服务器上保持功能清洁，但这对于保持功能分支清洁没有帮助。

Answer 1

我认为你应该使用＆＃34; merge＆＃34;解。不要重写历史记录，因为你永远不知道某人是否已经在你的老年人中。承诺，这可能导致未来的大混乱。 ＆＃34;合并＆＃34;中的历史图表。如果你正确地提交（原子提交）并编写好的提交消息，那么解决方案就足够清楚了解。