1

我们使用 git & github 作为我们的代码存储库。我的一位合同开发人员在 Windows 上，其余的则不在。windows 开发人员不得不对各种文件进行一些更改，以使项目在 windows 上运行。这些更改永远不应合并回主分支。除了这些更改之外，他还进行了我们希望合并回我们的主分支（经过我的审查）的提交（包括对他之前可能已经做出特定于 Windows 的提交的文件的一些提交）。

我最初解决这个问题的尝试失败了。我们为他创建了一个特殊的分支“windev”并将其添加到 origin。他将他最初的特定于 Windows 的提交提交到跟踪远程分支的本地 windev 分支，然后继续在这个分支中专门工作，向它推送。最初，我想，好吧，我只是挑选他的相关提交，因为我不想将他的特定于 Windows 的提交合并到我们的主分支。这可以很好地将好的提交提交到我们的主分支。问题是他还需要定期从 master 更新他的 windev 分支以获得最新的代码库。我们从尝试 rebase 开始，但它似乎造成了混乱，根本没有很好地处理樱桃选择或特定于 Windows 的提交。所以我' 每次他想更新他的代码时，他一直让他从主分支合并，但问题是他的分支中有重复的提交，因为我选择了他的每一个提交。我还怀疑这些重复提交会导致不必要的冲突和潜在的代码丢失。

我正准备和他重新开始，因为这似乎有点混乱，而且我担心它会产生错误或不必要的、容易出错的冲突。但我正在尝试找出适合这种情况的最佳工作流程，但我有点困惑。有任何想法吗？（PS 他是 git 的新手，对它感到困惑，所以我试图为他保持简单。我更愿意自己处理工作流程的任何复杂部分。）

4

2 回答 2

3

只需为使其在 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在合乎逻辑的工作点合并，这应该可以正常工作。

于 2012-08-10T18:55:05.220 回答
0

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

我能看到的所有其他可能性似乎都非常复杂：他有一个从不推送的windev分支，该分支永久基于/remotes/origin/master ，并且他在master分支上提交，但始终必须在运行包含更改的软件之前检查windev他做成了windev，所以不是那么好。

我认为其他钩子可能是值得的，比如每次他提交master 时都会在master上 rebase windev 。

于 2012-08-10T17:21:57.250 回答