When I first learned git, I thought I understood it all. I had a grasp of the process of cloning a repository, making your own changes, and then making a pull request. I had made sense of it by making analogies to the old days when I worked in subversion. But then, I started to think about how to use git in production. And the question dawned on me: how do I synchronize with the master branch of the repository that I forked from? I understood the workflow of having a lot of local repositories and one remote, but when in came to multiple remote repositories, I was lost.
As it turns out, it’s easy to set up. First, make sure you’ve forked a repository, and have cloned your version locally.
1
|
|
Then, if you’re in the local directory of your cloned repository,
1 2 |
|
You can see your configured remote repositories by running,
1 2 3 |
|
Then add the remote repository that you forked from as “upstream,” like so,
1
|
|
Then, if you run git remote -v again,
1 2 3 4 5 |
|
You will see that you have added a new remote.
Now that we’ve set that up, you can now easily synchronize your fork. First, fetch the remote repository,
1 2 3 4 5 6 7 |
|
Then, make sure you’re on the master branch,
1
|
|
And then merge in the changes. You may have some merge conflicts (if, say, you’ve been taking some lecture notes),
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
If there are no conflicts, the changes will be commited automatically. If there are merge conflicts, add your changes and commit then:
1 2 3 |
|
And now, you’re done.
The benefit of setting this up is that you can easily merge in the latest changes from the master of the project, but also have your own version. You can also not worry about accidentally pushing to the master of the repository you forked from.
The benefit of this for me, currently, is that I’m a student at The Flatiron School. Our lecture notes are a repository. By doing this, I can take better notes in lecture. I like to try to keep up, and type everything that’s happening in lecture. If I find that I have a typo or some other issue, I’ll forget about it and keep writing stuff along with the instructor. Then, when lecture is over, I’ll merge in what was happening in lecture, fixing everything that wasn’t working during lecture. I find that by doing this, I’m more engaged in lecture and the information sticks.
As a side note, watch out for duplicate migrations. If you’re following everything in class, you probably would have created the same migrations as the instructor but at a slightly different time. Just delete one of the duplicates and then commit your changes.