Git proper method to keep multiple remotes in sync?

Question

Here's the setup. I have a main github repository I'll call team/repo, and also a fork of it, which I'll call me/repo. On me/repo I made some changes in the feature branch (there is also a master branch), and create a pull request to the develop branch in team/repo. What is the proper method to get all the changes from the develop branch in team/repo (including the pull request I just made) back to the master branch on me/repo?

Answer 1

In reality, there is no "proper method", there are only different strategies/flows which different teams adopt.

Gitflow branch management model?

It sounds like you might be following the Gitflow model of branch management. Under Gitflow, you have a master branch, which is a semi-untouchable, set of commits that represent permanent copies of released code. You also have an active develop branch (possibly more than one), release branches, and feature branches.

Syncing a Fork

Since you have a fork of the repo, that's on Github as well (if I understand you right), and then you will also have a local repo on your PC. Normally you would setup the fork (me/repo) as a the standard origin remote, and then setup the original team/repo as a remote called upstream. When you want to update your fork, you pull down from the team repo (upstream) and then push those changes up to your fork (origin). If this part is any trouble, see This Answer on "Syncing A Fork".

You may already have all this setup - it's not clear. If it's not setup this way, the following may be off target.

How do you get changes from A to B?

Now the heart of the answer - how to get your changes from local/fork ( to team/repo (or upstream, the original team central repo).

First, consider if the fork is necessary. It likely is, but unless there are trust issues or this is a large distributed (likely multi-team) project, or open-source, the fork might not be needed. If you can, consider just working in a feature branch directly in team/repo and avoiding the added complexity of the fork.

Assuming the fork is needed, you a using a feature branch, and doing a pull request to team/repo on the develop branch. This is fine, and will get your changes into the develop branch, either as a rebase in a series of commits, or as a combined single commit.

From here, it totally depends on your team's workflow as to how/when that change gets to master. If the development follows Gitflow, there is no need for it to immediately going to master. You should be branching your feature branch out of develop, not out of master. And after your PR goes into develop, then just pull down the new develop commit into your local repo, and push up to your fork, and either create a new feature branch off develop or continue working in your existing feature branch until the next PR is needed.

Eventually, the team will merge develop commits into master, and possibly some of that will end up in release branches as well. If so, there might be a time where you need to branch off master or a release branch instead of develop, but the new features should be branching off of develop, not master (develop would merge to and split back off of master).

Your team may handle this differently, but this should give you a feel for how it works and allow you to ask the right questions. The main point is there is not necessarily a problem here, where your changes need to immediately get into master. If they do put it into master, you will still pull them down from upstream, though you may need to checkout your local master and merge it to upstream/master to fast-forward it, then push that to your fork.