A (self) reminder
I’m writing this brief note more as a (self) reminder than anything else. The reality is that I arrived at a point in my professional evolution when I do less coding and more product and people leadership.
This does not mean, however, that I do not do coding at all. Whenever the day-to-day activities leave in me some energy, I’m trying to learn a bunch of things, from Kubernetes, to Angular, to Node to Machine/Deep learning and AI to the latest in Cloud technology.
So my current pattern looks something like the following infinite loop:
- Start learning a new technology on my bucket list
- Start cloning the instructor’s code examples from Github
- [Something else happens, e.g. business travel, major work delivery, tiredness, keep the house lights running and so on]
- Forget everything you learnt at the beginning
- [Some more spare time makes its way into my life]
- Start from the beginning
When starting to learn a new technology, I tend to rely more on video courses because I find them easier and lighter to follow. Generally an instructor has some code on Github and the beginning of the course starts with a request to the students to clone the author’s Github repository.
However, I normally want to make changes to the author’s code, in order to better understand what I’m learning, therefore I normally fork the author’s code and create my own repository, also because this way I can push changes, experiments while keeping track of all the changes I made. This is where knowing how to keep a Github forked repo in sync with the original author’s version is not only handy but also necessary.
The procedure for doing so is really easy and Github documents it in these two articles:
I don’t intend to rewrite these two articles but I’m writing this post mainly to remind myself (and possibly others) of a quick way to condense these two posts into one set of instructions, so when I go back learning something that I temporarily set aside, I don’t need to go chasing Github articles around, I can refer to my blog.
Configuring a remote for a fork
The first thing that I will normally do is to clone my own forking repository, with a command similar to this one (note that I used SSH; some users might prefer https):
git clone git@github.com:myusername/my-project.git
The command above will create a “my-project” folder at the path where the command was run.
Adding the remote to the author’s original Github repo
The next step is to add to my cloned repository the information of where the author’s original Github repository is located. This is done by adding a remote to the Git project configuration. One needs to decide how to call the author’s original repository). The Github articles mentioned above suggest the name upstream. So we need to add remote information to our Github project that say: the code you were forked from resides at this address and I’ll give call it upstream. The command to add such remote is thus:
git remote add upstream https://github.com/original-author/original-project.git
Now that my local Github repository configuration knows where the original code resides, I want to fetch all the original code with the following command:
git fetch upstream
This command will download all commits, files and refs from a remote repository to the local repository. If you want to know more about what git fetch does, refer to this article from Atlassian.
At this point I’m normally in the situation where the original author’s repository has moved ahead compared to my fork and I want to bring my (normally master) branch in synch with the author’s. I then execute the following commands (assuming I want to sync the master branch):
git checkout master --> This is my local master branch git merge upstream/master --> This merges the author's original with mine
These commands will automatically merge all code from the original’s author master branch to my own master branch. Finally, if I’m happy with the latest changes, I can push them to my repository with the command:
git push
Leave a Reply