我是项目的唯一开发人员。 举个例子，假设我有以下情况：
Office A - 对代码进行更改，提交，然后推送
Office B - 尝试拉更改，但如果有任何更改，则会进行投诉。我想忘记所做的任何更改并获得最新版本。
基本上我在办公室之间切换A＆amp; B，每次我想提交对远程存储库的更改，然后从下一个办公室再次获取这些更改。 Git会抱怨，因为工作副本可能会有一些细微的变化。我一直在使用 git reset --hard ，接着是 pull ，但这种感觉不太合适。我也查看过 stash ，但这似乎可以保存更改，以便以后使用。
git的命令数量似乎令人费解！
答案 0 :(得分：0)
起初你应该养成经常做事的习惯。基本上，您执行的每个步骤都可能导致提交。这些在git中并不昂贵，但由于通常的工作粒度在提交级别上，因此可以使您的生活更轻松。你也购买了这个实验和测试，你永远不知道这些代码部分何时变得重要：）
一旦你开始提前和经常提交，你应该开始养成使用主题分支的习惯。与...不同SVN，分支机构也很便宜。分支基本上只是指向提交的指针，即分支的HEAD，因此它与标记没有太大区别。使用分支是git的核心，为您找到git的使用模型的任务基本上解决了找到适合您和我们工作流程的分支模型。
因此，您应该开始为您开发的每个功能使用单独的分支。完成后，您可以将分支合并回mainline / master / whatever，然后删除分支。这种方法的优点是，您可以相互独立地开发您的功能，而不需要过早Experience Bij。
现在，如果您已经提交了所有内容并将内容放入整齐的分支中，则可以将所有分支推送到服务器。由于您在本地存储库中没有任何未提交的更改，并且您始终在现有提交之上工作，因此您不应该有任何合并冲突，因为分支只是快速转发。
答案 1 :(得分：0)
在从主工作站管理开发以及在笔记本电脑上移动时，我做同样的事情。有时我会在笔记本电脑上有一些我正在处理的东西没有得到承诺所以当我试图从主回购中拉出来时会有冲突。我会git diff查看我正在处理的内容，然后决定是否需要stash或reset这些更改。
答案 2 :(得分：0)
你（和git）完全按照你的意愿去做。你没有错误地使用git;它的目的是能够像这样从不同的地方推拉。
git抱怨你的原因，是因为变更集模型需要它：假设在机器A上，你使用散列“abcdef”进行了提交。为了能够像您想要的那样在存储库之间共享变更集，提交“abcdef”必须完全相同，无处不在。在计算机B上，当您将该提交提取到本地更改时，它可能会将该提交放入某个特定位置的历史记录中，但它不能混合提交您的本地更改。这样做会产生提交“3dea12”，这完全不同。
Git可以尝试动态混合您的更改，就像颠覆一样。但是，考虑一下，如果你已经提交了六次：现在你必须合并六次，一次为另一台机器上应用的每次（不可分割）提交。 Subversion通过总结diff的all-in-all blob中的更改来解决这个问题，然后尝试将其置于本地更改之上。它有时会起作用，但有些合并会变得有点棘手，不会让你保持git提供的整洁，变化，永不改变的历史。
要解决您的问题，这是您在机器B上的拉动策略：
$ git stash # Set your uncommitted changes aside for a moment
$ git pull # Pull in the new changes
# <resolve conflicts, if they happen>
$ git stash pop # Bring back your uncommitted changes, fixing ambiguous
# merge pieces as necessary.
基本上，这就是“不要担心，git stash并不可怕”，策略。 ：）
我认为注意你必须合并是很重要的。良好的开发实践，保持较小的变化等可能会使合并更少发生，但您有时仍需要合并。
顺便说一句，你想要 git抱怨。如果你的工作副本是干净的（不需要藏匿），你就是将一个历史记录与另一个历史记录混合在一起。 Git会找到你需要合并的地方，并问你该怎么做。这是一个非常明确的过程。如果它必须将这些点与以及的局部变化混为一谈，那么历史就会变得非常混乱。这基本上是将过去的事物与“未来”中的事物合并，在这种情况下，这是你未承诺的工作（可能会改变！）。
鉴于此，这是你的另一个选择：
$ git commit -m "..." # Commit your local changes, making them part of history.
$ git pull # Clean working copy! (maybe merging required)