git工作流挑战为双向合并永久分支和一些不应该合并的差异

Question

我们使用git & github作为我们的代码存储库。我的合同开发人员之一是在窗户上，其余的不是。 Windows开发人员必须对各种文件进行一些更改才能使项目在Windows上工作。不应将这些更改合并回主分支。除了这些改变之外，他还提交了我们想要合并回我们的主分支（在我的评论之后）的提交（包括一些他以前可能提交给windows特定提交的文件的提交）。

我最初尝试解决这个问题是失败的。我们为他创建了一个特殊的分支“windev”，并将它添加到了原点。他将自己最初的Windows特定提交给当地的windev分支，追踪远程分支，然后专门在这个分支上继续工作，推动它。起初，我认为，好吧，我会选樱桃挑选他的相关提交，因为我不想将他的Windows特定提交合并到我们的主分支。这很好，可以让我们的主分支得到很好的承诺。问题是他还需要定期更新他的windev分支以获得最新的代码库。我们开始尝试使用rebase，但是它似乎造成了一个令人困惑的混乱，根本没有处理好樱桃挑选或windows特定的提交。所以，每次他想更新他的代码时，我一直让他从主分支中合并，但问题在于他的分支中存在对樱桃挑选的每个提交的重复提交。我也怀疑这些重复的提交会导致不必要的冲突和潜在的代码丢失。

我即将准备好与他重新开始，因为这似乎有点混乱，我担心它会产生错误或不必要的，容易出错的冲突。但是我正在努力研究这种情况的最佳工作流程是什么，并且有些困惑。有任何想法吗？ （PS他是git的新手，对此感到困惑，所以我尽量保持简单，我宁愿自己处理任何复杂的工作流程部分。）

Answer 1

只需构建一个永久性分支，让它在窗口上工作所需的更改，然后重新编译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，这应该工作得很好。

Answer 2

您可能会感兴趣smudge clean哪些是他可以用来在修改他的工作目录之前应用他的更改并在提交之前删除的钩子。理想情况下，它只是一个告诉windows或linux的标志，你的应用程序会在需要的地方查看这个标志。

所有其他的可能性我可以看到似乎很复杂：他有一个windev分支，他从来没有推动其在/遥控器/产地/主永久重建基础，他承诺在主分支，但总是有结账windev在运行软件之前，把他所做的修改变成了windev，所以不太好。

我想其他hooks可能是值得的，就像一个重订windev上每次他犯下对主时间主。