将本地 git fork 存储库分支与远程原始分支的更改同步
我发现了很多问答关于将分叉的 git 存储库与原始远程存储库同步，但没有一个适用于我的确切问题。
假设我分叉了一个远程名称为“upstream”的项目，我的分叉名称为“origin”。我在本地有一个 master 和一个 dev 分支，用于跟踪 master 和 dev 的 origin >。
只要我不对我的分叉存储库进行任何更改，我就知道我可以将我在源的分叉存储库与上游/主同步到目前为止
git checkout master
git pull upstream master
git push origin master
，一切都很好。但现在我在本地 dev 分支上工作，一旦完成，我想将其合并到我的本地 master 中。 向我的本地大师通报上游的最新变化
git checkout master
git pull upstream master
git push origin master
但首先我会通过第一个问题 ： 这是正确的吗？但是我该如何处理我的本地 dev 分支呢？在将其合并到我的本地 master 之前，在我更新的 master 上对其进行变基，或者尝试在不变基的情况下合并它？或者我应该尝试通过时不时地引入上游/master来使我的本地dev始终与上游/master保持同步？
完成此操作后，我将
git push origin master
删除本地和源中的 dev 分支。但现在我的master（本地和起源）由于我的本地dev所做的更改而偏离了上游/master >。
第二个问题： 现在与上游/主控保持同步的正确方法是什么？我仍然简单地这样做
git checkout master
git pull upstream master
git push origin master
还是这里推荐其他任何东西（例如某种形式的变基）？如果我再次创建分支 dev，我会再次应用适用于第一个问题的相同策略还是会应用其他策略？
感谢您的帮助！
I found a lot of q & a about synchronizing a forked git repository with the original remote repository but none applied to my exact problem.
Let's assume I forked a project with a remote name of upstream, my fork's name is origin. I have a master and a dev branch locally that track master and dev of origin.
As long as I make no changes to my forked repo I know I can sync my forked repo at origin with upstream/master by
git checkout master
git pull upstream master
git push origin master
So far, so good. But now I work on my local dev branch and once I'm done I would like to merge it into my local master. But first I would bring my local master up to date with the changes in upstream by
git checkout master
git pull upstream master
git push origin master
First Question(s):
Is this correct? But then what would I do with my local dev branch? Rebase it on my updated master before merging it into my local master or try to merge it without rebasing? Or should I try to keep my local dev in sync with upstream/master all along, by pulling in upstream/master from time to time?
Once this is accomplished I would
git push origin master
and delete my dev branch, locally and in origin. But now my master (locally and in origin) deviates from upstream/master by the changes made by my local dev.
Second Question:
What is the proper way to go now to keep in sync with upstream/master? Do I still simply do
git checkout master
git pull upstream master
git push origin master
or is anything else recommended here (e.g. some form of rebasing)? If I created a branch dev again, would I apply the same strategy that applied for the first question again or would something else apply?
Thanks for your help!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
问题 1：
我认为无论哪种方式都可以。根据我的经验，这样的事情通常效果很好：
，这种方法就有效。完成 dev 后，您可以再次变基，然后在 master 上合并，或者直接在 master 上合并。您可能想要更改合并提交中的消息以指示合并中的内容。
问题2：
从上游合并时，只要您的本地或源没有任何不同的更改，合并就会快进。这基本上意味着 git 只是将来自上游的提交堆叠在您拥有的任何内容之上，并且不会合并冲突或任何内容。
因此，您不需要重新设置基准或任何其他操作。如上所述，如果您在开发方面工作，那么此时对开发进行变基可能是个好主意，这样您就可以使其更新。
当您进行与上游不同的更改时，您将进行实际合并，并且如果您愿意，还可以进行变基。
变基还是合并？
这主要取决于您以及您喜欢的工作方式，但如果您考虑变基，请记住它会改变历史。
如果其他人正在使用 origin/master 或 origin/dev，并且您对其进行变基，那么他们在尝试合并其工作时可能会遇到一些问题。因此，通常如果一个分支由多个人使用，您应该使用合并。如果超过一个人使用一个分支，切勿使用变基（或任何其他改变历史的东西）。
Question 1:
I'd say either way is fine. In my experience something like this usually works pretty well:
Once done with dev, you can either rebase once more and then merge on master, or simply merge directly on master. You may want to change the message in the merge commit to indicate what was in your merge.
Question 2:
When merging from upstream, as long as you don't have any differing changes on your local or origin, the merges will be fast-forwards. This basically means git just stacks the commits from upstream on top of whatever you had, and there will be no merging of conflicts or anything.
Because of this, you don't need to rebase or anything. As mentioned above, if you work on something on dev, it may be a good idea to rebase dev at this point so you'll have it more up to date.
At the point where you have changes that differ from upstream, you will have an actual merge and the possibility to do a rebase if you so wish.
Rebase or merge?
This is mostly up to you and how you like to work, but if you consider rebasing, remember that it changes history.
If anyone else is using origin/master or origin/dev, and you rebase it, it's possible they will run into some issues when trying to merge their work back. So generally if a branch is being used by more than just one person, you should use merges. Never use rebase (or anything else that changes history) if more than one person uses a branch.