双向合并具有一些不应该合并的差异的永久分支的git工作流挑战
我们使用git & github作为我们的代码库。我的一个合同开发人员在windows上，其余的都不是。windows开发人员必须对各种文件进行一些更改，才能使项目在windows上运行。这些更改永远不应该合并回到主分支中。除了这些更改之外，他还会提交(包括他之前可能对某些特定于windows的提交的文件的提交)，我们希望将这些提交合并回我们的主分支(在我审核之后)。
我最初尝试解决这个问题的尝试失败了。我们为他创建了一个特殊的分支"windev“，并将其添加到origin。他已经向本地windev分支提交了他最初的特定于windows的提交，该分支跟踪远程分支，然后继续在此分支中专门工作，并推送到该分支。一开始，我想，好吧，我会精挑细选他的相关提交，因为我不想把他的特定于窗口的提交合并到我们的主分支。这可以很好地将好的提交放到我们的主分支中。问题是，他还需要定期从master更新windev分支，以获得最新的代码库。我们从尝试rebase开始，但这似乎造成了混乱，根本不能很好地处理挑剔或特定于窗口的提交。所以，每次他想要更新他的代码时，我都会让他从master分支进行合并，但这样做的问题是，对于我精心挑选的每个提交，在他的分支中都有重复的提交。我还怀疑这些重复提交会导致不必要的冲突和潜在的代码丢失。
我准备与他重新开始，因为这看起来有点混乱，我担心它会造成错误或不必要的、容易出错的冲突。但我试图找出这种情况下最好的工作流程是什么，我有点困惑。有什么想法吗？(附言:他是git的新手，并且对此感到困惑，所以我试着为他保持简单。我更喜欢自己处理工作流程中任何复杂的部分。)
回答 2
Stack Overflow用户
发布于 2012-08-11 02:55:05
只需为在windows上运行所需的更改构建一个永久分支，并使用他编写的每个功能重新构建windev (即每次他需要在本地更新master时)。
这听起来比实际情况更复杂，我已经成功地使用它在Tomcat应用程序中管理了一组长时间运行的并发的、互斥的配置更改(即，不同生产环境下的多个版本的META-INF/context.xml )。
git checkout -B permanent master ;# check out a "permanent" branch
< make required windows changes and commit >
git checkout -B windev master ;# this is the branch he uses for new work
git merge permanent ;# merge 'permanent' into 'windev'因此，现在他暂时停止了工作。您使用cherry-pick，这在您这一端是可以接受的。当他需要将master重新合并到windev中时，这可能发生在他完成了某种功能或项目，而您精心挑选了他的新工作时，他只是发出以下命令：
git rebase --onto master master permanent ;# rebase permanent onto newest master
git checkout -B windev master ;# reset 'windev' to 'master'
git merge permanent ;# and merge in the required changes实际上，每隔几天/几周就会发出这最后三个命令。如果他非常凌乱，并且在他的本地周围保留了大量的WIP，或者严重依赖于其他团队成员的工作，这可能是不够的。如果他是相当孤立的，并且只需要在逻辑工作点合并到master中，那么这应该可以很好地工作。
Stack Overflow用户
发布于 2012-08-11 01:21:57
您可能对smudge clean感兴趣，他可以使用这些挂钩在修改他的工作目录之前应用他的更改，并在提交之前删除它。理想情况下，它只是一个告诉windows或linux的标志，您的应用程序将在需要它的地方查看此标志。
我能看到的所有其他可能性看起来都非常复杂:他有一个windev分支，他从来没有推过这个分支，这个分支是永久重新基于/remotes/origin/master的，他在master分支上提交，但在运行包含他对windev所做更改的软件之前总是必须检查windev，所以不是很好。
我认为其他hooks可能是值得的，比如windev每次在master上提交时都会将其重新设置为master。
https://stackoverflow.com/questions/11906314
复制相似问题
腾讯云开发者
