问题标签 [git-workflow]

我们的项目分为 4 个不同的 Git 项目（层次结构），其中叶项目是客户部分。

为了发布新版本，我们使用 (SourceTree) 和 GitFlow-Feature。因此，从最新的 dev 分支中创建了一个新分支，在完成发布后，它将被合并回 dev，并填充到 master-branch。

为了更容易开发，我们曾经为所有项目使用固定版本（“dev” insetead of xyz），同时在开发分支上工作并设置实际版本，每当我们将分支填充到发布分支时。

因此，我们希望避免将 pom 文件合并回 dev-branch。（pom 中定义的版本应与dev保持一致，而所有其他（最终）更改应合并回 dev。）

有没有办法在不重新发明轮子的情况下实现这一目标？

因此，在完成发布后：

• 填充对主分支的所有更改
• 将更改合并回开发分支，除了 pom 文件？

我正在一个分支（和其他人）关闭主人。

我们会定期将 master 合并到分支中，以尽量减少以后的冲突。

最终，我们会想要合并回来。

我可以合并回主人的最干净的方法是什么？

1. 我想保留个人提交（即没有壁球）
2. 我不会再使用branch-a了，所以提交哈希可以改变。
3. 如果可能的话，我不想在没有冲突的情况下包含合并提交（例如H，L）。

理想情况下，它看起来像这样（假设没有冲突）：

关于如何做到这一点的任何想法？

（仅供参考，这是关于我的工作流程的问题。如果我应该早点做其他事情，那也是一个合理的答案。）

更新：

在考虑了更多之后，我意识到这通常是不可能的。

例如，如果J更改了已更改的行G，则无法获取该历史记录。

下一个最佳选择是拥有这段历史：

本质上，这是一个变基，但省略了不必要的合并提交。

我正在与一个不熟悉 git 的开发人员合作，我想设置一个 git 工作流程，让我可以审核该开发人员所做的提交（并可能拒绝它们），而不会强迫他重新调整他的工作（这很容易出错对于新用户）。

这是场景：

• 该master分支仅包含经过审核的代码
• devel分支是通过分叉master分支创建的
• 开发人员正在devel分支上工作并推送他的代码供我审核
• 我发现他的代码存在一些问题，所以我要求他在devel分支上进行更多提交以解决问题
• 一旦我对代码感到满意，我就会挑选（或与 squash 合并）开发人员在master分支上提交，添加我自己的评论并将提交标记为由开发人员编写
• 开发人员将分支合并回master他的devel分支

这是此场景的可视化说明：

在这个序列之后，当开发人员在其他一些提交后再次推送他的分支时，我怎么能100% 确定开发人员在“犯错误/重做”序列中犯的错误不会再次出现？devel

最好的解决方案是要求开发人员将他的devel分支重新设置为基础master，但这对于新的 git 用户来说是一项艰巨的任务。

如果此工作流程有任何错误，请建议我另一个可以在将提交合并到主分支之前审核提交的地方。

编辑

一位朋友向我推荐了一个看起来很有希望的方向：提交时的--fixup 选项。

--fixup=<commit>

构造一个提交消息以用于rebase --autosquash. 提交消息将是来自指定提交的主题行，前缀为“fixup!”。有关详细信息，请参阅git-rebase。

开发人员可以使用此选项将他的第二次和第三次提交正确标记为对其第一次提交的修复。一个很好的解决方案来探索......

有两个分支：
- 生产分支，其中包含客户接受的产品
- 开发分支，开发人员在其中进行令人毛骨悚然的实验
曾几何时，年轻的开发人员决定从生产分支分支他的超级功能。
所以问题：
1）。如何在不合并 prod 分支的所有特性的情况下将生产分支转移到开发。图片解释得更好：

第一个问题是为了练习，另一个问题是为了好奇：
2）。与 1) 相同 + 我还需要从生产中保留功能分支
3)。像 1），但我想要传输一致的提交集“F”并且不希望传输“E”提交
4）。我想转移 E 和 F，不包括 2 个提交，1 个来自集合“E”的提交和 1 个来自集合“F”的提交。
5）。 我可以自动解决冲突以支持其中一个分支吗？

我找到了git cherry-pick命令，但似乎这不是整个分支的最佳方式。我应该学习git rebase还是其他？哪种方式最适合我的问题？

感谢并为我糟糕的英语感到抱歉。

我们的团队已经使用 GIT 实现了一个分叉工作流，其中

• 我们有一个中央存储库（主）
• 其中一位开发人员被分配了项目维护者的角色
• 另一位开发人员已经对主存储库（fork）进行了 fork，并将本地更改推送到 fork。项目维护人员审查开发人员对开发人员（分叉）存储库的每个提交。
• 每次更改都会创建一个分支。
• 代码审查员审查每个提交给 master 的提交。

项目维护者有责任确保提供约定级别的代码质量，并测试来自其他开发人员的集成。因此，开发人员和项目维护人员可能会在同意将更改推送到 master 之前进行几次提交迭代。

另外，项目维护者可能会在推送到master之前在本地更改开发者的代码。

目前，所有开发人员的提交都被发送到 master。但是，需要的是开发人员的提交不会显示在 master 上，而是由维护人员滚动到单个提交中（可以这么说）。

如何使用 git 来实现这一点。因此，在上图中，主审阅者应该只看到 qa_branch1 的提交 1。

我在一个团队工作，我们有一个名为 development 的分支。从该分支我在自己的计算机上创建了另一个本地分支。当我在本地分支上时，运行命令“git merge development”有什么区别和我当地分支机构的“git push origin development”？

git 新手，每个团队对最佳工作流程都有自己的理论。

我尝试使用 GIT 几周。并尝试使用 Git 了解一些工作流程。然后我设置了一个 Gitlab 服务器进行权限管理。环顾 GitLab 服务后，我注意到 gitlab 通过嵌入式按钮支持分叉工作流。还支持保护分支的能力。

我认为“受保护的分支”功能可以用来替换叉子按钮，我是对的还是有一些我不明白的概念？

这就是我这么认为的原因：在fork-workflow中，只有维护者才能推送到官方仓库，所以合作者将官方仓库fork为上游仓库，将上游克隆到本地工作副本，在本地完成一个特性分支后我们推送到我们的上游比对维护者的拉取请求，但如果我们想用官方仓库获取分叉仓库，我们通过拉取官方仓库并推送到上游来完成。它....我不知道...有点太非自动，不像在团队中工作。

但是使用受保护的分支，上游没有fork，合作者有权限推送到官方，但只有维护者可以推送受保护的稳定分支，我们不需要手动同步fork repo。维护者不需要添加许多遥控器来获取合作者的新功能。

这是一个方便的版本分叉工作流程吗？并且可以完全替代叉子按钮？

目前我们正在使用 TFS 2010 并计划迁移到 TFS 2012。作为我们新项目的一部分，我们希望将 git flow 工作流作为我们的分支策略。

这需要跨分支合并，我可以在 tfs 中使用 baseless 合并来做到这一点。然后我失去了所有更改或项目合并的跟踪。

TFS 2010 / 2012 中是否有任何方法可以对交叉分支进行增量合并？就像在 git 中推拉一样？

Нi。我对 Git 相当陌生，但我们将在我们的项目中使用它并寻找方便的工作流程。Gitflow 对我们来说相当好（http://nvie.com/posts/a-successful-git-branching-model/)，但有一些修改。问题在于，在发布时，开发中并非所有功能都通过了测试，并且不能包含在发布分支中。所以我们不能从开发开始发布分支。如果我理解正确，我应该从最后一个发布标签开始所有功能分支和发布分支。将功能分支合并到开发中。但是没有反向合并到该功能中。当功能准备好发布时，我应该直接将它合并到发布分支。所以我必须做很多合并（当前准备发布的 sprint 的每个任务都必须合并），而不是与经典 gitflow 中的开发进行一次合并。每个 sprint 可以是 10 个分支。看起来真的不太好。那么在这种情况下有什么方法可以减少手工工作吗？或者也许我在这种情况下错了，还有其他适合我的情况的工作流程？提前致谢！对不起我的英语:)

我了解典型的 Git 工作流程是一个三步过程：（修改工作树中的文件）->（使用 修改索引git add/rm/etc）->（运行git commit）。

但是，为什么 Git 不把工作树当作暂存区呢？例如，您修改了一个文件，它会自动“暂存”以进行提交，除非您明确告诉 git 不要暂存它。这更像是一种“选择退出”方法而不是“选择加入”，这对我来说很有意义，因为您的工作树中 99% 的文件都将被提交。它还会使整个git stash机制变得多余，因为您可以简单地从工作树中创建一个临时分支，而不是稍后save存储apply。

如果工作树和索引之间的分离有正当理由，我很想听听......也许我的困惑源于我还没有完全了解 Git 的事实。