Question

我刚刚在http://learngitbranching.js.org/完成了所有可用的练习，现在我感到非常自信。我理解了所有这些，并且每次练习都不需要太多考虑。显然这些只是初学练习，我现在只是一个Git新手，但理解某些东西感觉很好。现在我可以正确地控制我的工作，而不是依赖于复制工作版本的文件。

无论如何，我有一个关于合并回可能会引入错误/

的遥控器的问题

考虑这种情况：

我在星期一检查了remore repo上的最新master分支，并在本地分支以处理新功能。这个特性可以说与自定义类中的一些类方法相互作用，

现在星期二，我的朋友检查了主分支，并在本地分支，并决定他有更好的方法让同一个班级运作。所以他继续前进并对类进行更改，可能会删除其中的一些方法并编写不同的方法。让我们说，他承诺这些改变，并在周三将它们推回遥控器上的原点/主人。

现在是星期四，我刚刚花了三天时间编写与已更新的类进行交互的新功能。假设我的功能需要我的朋友在更新类的工作方式时删除的一些类方法。我做了拉动和推动，会发生什么？

我假设发生的事情是当我拉我的文件时会更新其中的类和方法的最新版本，并且我的功能可能是一个单独的文件将与新主文件合并，因此包括一个引用一个文件的文件现在已过时的版本。因此，当我推动我只是推送不起作用的功能并且会有错误（或者更糟糕的是甚至不编译），因为它引用了不存在的方法。

这是常见的吗？如何在生产中解决这个问题？当特定课程发生变化时，您是否只需要口头沟通您的团队工作，并且任何与该课程相关的功能的人都需要将他们的功能建立在新课程上？

Answer 1

我假设发生的事情是当我拉我的文件时会更新其中最新版本的类和方法

你所做的实际上是：

git checkout yourBranch
git fetch
git rebase origin/master

这会在更新后的yourBranch重放origin/master。

然后你编译，检查一切是否正在运行，运行你的单元测试，.... 只有这样你才会推回你的分支，并发出拉取请求（GitHub）或合并请求（GitLab），以便触发代码审查并合并回远程master分支。

这个想法仍然存在：如果您的代码仍然有效，请在本地测试，然后回过头来进行代码审查（拉/合并请求）：这是通信自然发生的地方，通过代码评价。

Answer 2

我会说，确保您的功能有效，这取决于您。是的，更好的团队沟通将有助于确定此类冲突，但最终，是推动破解代码的人。

拉出并解决合并冲突（如果有）后，请确保该功能有效。运行测试（你有测试，对吗？）。如果您确信它有效，请推送。

另外，你的问题不清楚你是否这样做，但是，正如VonC所说：你没有推动掌握。您将分支推送到远程仓库，然后发送拉/合并请求。

如果您拥有某种临时环境（即新提交不直接进入生产环境），那么问题就不那么严重了。在这种情况下，即使您遗漏了某些内容，当有人在暂存时点击该应用时，也有第二次机会被检测到。

Answer 3

这是常见的吗？如何在生产中解决这个问题？当特定课程发生变化时，您是否只需要口头沟通您的团队工作，并且任何与该课程相关的功能的人都需要将他们的功能建立在新课程上？

是的，这听起来很常见，也不是git谁可以在这里做任何事情。我们作为开发人员需要确保我们定期测试我们的代码（周期性地像小时或每天）。

我相信这是你应该尝试的：