我绞尽脑汁想弄清楚什么是使用GIT的正确方法。我以为我明白了，但最近我们遇到了一些问题。我的情况是这样的，真希望我能找到一个简单的方法来解决我的问题。
2人(称他们为A &B)在同一个项目上工作。
A做的开发较少，但他负责审查B并将代码推向产品。
B做了大部分的开发，但不能推向生产，需要A审查和批准他的代码。
到目前为止，我们是这样工作的:
A正在研究master。
B正在开发分支'dev' - dev是一个远程分支，B正在向它推送更改，a可以从远程分支中提取。
A直接在'master'上进行更改(这些更改被推送到生产环境)。当B完成一个特性时，a将"dev"合并到master (git checkout dev;git拉;Git checkout master;Git merge dev)
B只在'dev'上工作，并告诉A何时合并。如果A在master上做了更改，B就会重新建立(git checkout master;git拉;Git rebase dev;Git checkout dev)
这似乎工作得很好(我们假设这是一种正确的工作方式)，但不知怎么的，即使在a合并后，B重新基于，'dev'不等于'master'。
我们做错了什么，我们应该使用不同的方法/工作流程来满足我们的需求吗?
- 注意:'dev'必须是远程分支，因为有时A帮助B解决问题，'dev'也被推到在线测试服务器，以便其他人可以测试。
我认为你误解了git rebase应该如何使用。你说当B想要将他/她的工作重新基于master时，开发人员会这样做:
git checkout master
git pull
git rebase dev
git checkout dev
当你在master上运行git rebase dev时，这就是说(粗略地)采取master中但不在dev中的所有提交，并尝试重新应用任何在master之上引入新变化的提交。您可能想要这样做:
git checkout master
git pull
git checkout dev
git rebase master
…因此，dev中的任何新内容都将重新应用于master之上。请注意，在这些命令之后，如果dev中没有任何新内容，您只会期望dev和master相同。
作为一个更一般的评论，在这种情况下，找出历史记录错误的最简单方法通常是使用一个工具，该工具可以显示提交图的图形表示形式。例如，如果你运行gitk --all，你应该能够看到master和dev在哪里，以及为什么它们没有像你期望的那样指向同一个提交。
另外，值得注意的是，为了避免重写发布历史记录可能引起的混乱，当dev分支包含尚未合并到master的已发布提交时，B可能希望避免执行重基操作。