So if you're like me, you've been having more and more conversations that are a bit of a stretch from your infrastructure roots. Everything turned software defined now that the cloud and cloud adoption have been gaining more traction over the years. I've noted something which can sometimes be a heady mess for me is source control. Turns out it's like most things in tech: the more you practice, the better you become.
Which leads me to the topic of this blog: did you know you can update a fork you create on GitHub? Because up until recently, I didn't.
First off, let's take a step back and define what a fork is, so everyone is on the same page. "A fork is a copy of a repository. Forking a repository allows you to freely experiment with changes without affecting the original project." Think of forks as a way for different users to contribute to the larger project or repo. You may want to propose changes or adjust content so it better reflects what is currently done to represent a solution (for example). In my current job, I had a whole heaping dose of forking recently and finally started to understand how it all works (again, if I can do it, so can you). Like most things, forks drift over time. Every time you update something on your fork, you will want to ensure your fork is up to date with the actual repo you're contributing to. So (for example) if you forked the Azure Docs a good long while ago (like I did), just know a lot has changed since your original fork. If you ever wanted to contribute to that repo now in 2021, you'd somehow have to update that fork beforehand.
"So how do you update that fork?" you may be wondering. Well, I'm here to help. Let's take the azure-docs repository on GitHub. You'll first want to create a fork to your own GitHub account (also, maybe I assumed too much - make sure you have a GitHub account of your own). Creating a fork is as simple as going to the main repo on GitHub and selecting fork at the top:
After you tie that fork to your own account, you should see a forked copy underneath your account. You will know it's your own forked copy simply by examining the top left:
Brilliant! You should be good to eventually fetch from the upstream source down the road. In my own example, note how far behind my current fork is:
76,396 commits behind master (newer repos use main). That's a whole lotta commits I'd be missing out on if I were to contribute to the Azure Documentation online. Since Microsoft open sourced Microsoft Documentation, it's a combined effort to maintain: Microsoft takes on product updates, features, etc., but if there are misspellings, typos, incorrect configurations, the community can contribute to the GitHub repo. Pretty cool, aye? Note that in order to contribute to the master or main branch of documentation, you'd need to ensure you are fetching from the upstream before creating a pull request (PR). You can now do that 1 of 2 ways. The first is with the git command line and updates what you have locally vs. on GitHub (I've always been told the recommended pattern is to start in the context of master or main for newer repos):
git remote add upstream https://github.com/MicrosoftDocs/azure-docs
git checkout master
git pull upstream/master
If you're ever worried you've made a mistake throughout the process of setting up your origin or upstream (if this is foreign to you, let me know and I'll craft out a separate blog about source control terms), simply run git remote -v. You'll see exactly how you've configured your local set-up in relation to the remote repository. Here's a screen shot of me setting this up locally:
Seems slightly complicated, right? "What about that other way you mentioned?" you may be wondering.
Remember that screen shot up above that showed my fork as being almost 80,000 commits behind master? Did you see what was on the far right? Fetch upstream! This means you can keep your fork updated ON GitHub!
Select Fetch upstream and you will be prompted with a similar dialogue prompt as what I show below:
Select Fetch and merge. Then you should see a similar message as what I show below (namely that the fetch and merge were successful):
WAY easier, right? I REALLY love this new GitHub engineering feature that helps you keep your forks current as time moves forward (because it never moves backward).
My hope is this helped you! Keep those forks current and keep on contributing to GitHub repositories EVEN IF you might have some ever so slight impostor syndrome, as you're doing things that normally developers used to do.
Cheers!
Comentários