It is pretty often that we need to work with a team of developers.
Sometimes we need to share our code; and with Git having the ability to work with multiple “remotes” is really convenient.
Think of the “remote” as simply the URL of the repo where you push your updates.
Let’s dive into an example…
Mike has been doing some development in his feature/adding-new-report branch.
It would be awesome for me to work in my own branch (as any good git user will do), yet I would also love to be able to easily sync our work.
Thankfully with some modern tools and “Pull requests” available on most git hosting sites (github, stash, bitbucket, etc.), we can do it very easily.
The method below would also work just fine without “pull requests” but for the simplicity and an extra step of sanity-checks, I recommend using PR’s when possible.
So now we can consider a typical setup.
You have a central repo at the remote (destination) called “origin”, where the code of your application lives. When we refer to “origin” in git, we are really talking about some destination (or URL) pointing to the git repo somewhere out there.
With that said, it is also not uncommon for each developer to clone the main repo, work on their own copy and then submit their changes by merging the changes in, or creating a “pull request”.
We can easily add other remotes besides “origin” (which is, by the way, just a name given to the initial repo destination. It can be changed, moved and you can add more destinations as we’ll see below).
Let me add Mike’s remote so I can checkout code from his repo (not just “origin”).
Now we have a new remote called “mike”
I can create a local branch to sync up with Mike’s changes:
Now we have a local branch called feature/adding-new-report. It is “connected” (tracking) with Mike’s branch in his repo.
Pretty cool.
Now we should get the latest changes into our local branch. (Presuming we are now on our local feature/adding-new-report branch).
(Got the latest code from Mike).
Now we can make any changes and commit them as usual.
At this point we have a couple of options. We could just push the changes up to Mike’s branch/repo.
Additionally (and preferably, in my opinion) we could do the following:
This will create the same branch in our own remote repo (presuming “origin” points to the URL of my development repo). This enables us to create a pull request, which will clearly show the differences between my changes and the current state of Mike’s branch. (if we were diligent about keeping things up-to-date only the necessary changes without conflicts should be shown in the diff.)
Overall there are a few benefits to using pull requests. You can easily see what was changed, the PR can be updated, based on review (you can add multiple reviewers) and it keep things a lot more cleaner and organized. (Dealing with conflicts is a bit easier).
For reference here’s github’s overview of working with Pull Requests.