GitHub: Working with Git Forks for Pull Requests

Keeping a Fork in Sync with the Original

While opensource projects are meant to allow contributors to create modifications and submit those modifications back upstream, the process for doing so isn't always clear.  In a rapidly changing source repo, making a fork and keeping that fork in sync with the upstream (original repo) just so that you can submit a pull request can be tricky if one doesn't know about a few tricks.  This article explains one of those tricks in keeping a copy of the upstream repo as the master branch locally on your PC while your new feature branches pointed at your forked repo.

Step 1 - Fork the Original Repo

Most open source projects do not allow you to create a branch in the master project, which requires contributors to fork the original repo so that you can make changes there first before submitting the change to the upstream repo in the form of a pull request. The first step is to of course fork the original repo.  In GitHub, this can be done by clicking on the Fork icon at the top of the open source project you are working with.

Step 2 - Clone the Original Repo to Your PC

Once the fork is created, its time to clone this or the upstream repo to your PC so that you can create a new branch and begin editing the source code.  The clone can be done from either the fork or the upstream repo.  Either will work as we rebase-ing the fork with the upstream on a regular basis.

git clone [your clone URL here]
# assuming the clone was the upstream do the following to rename it to upstream
git remote rename origin upstream

Step 3 - Point Master Branch to Upstream

Now that we renamed the origin to upstream, we need to ensure that the master branch we obtained still points at this upstream repo (and not our fork). this is done by:

git branch -avv # existing branches like master are linked to upstream/xxx

Step 4 - Add the Fork URL as a new Remote

Now we need to add back in a new origin pointing at our fork so that all of our new branches point back to the fork and not the upstream repo.

git remote add origin [your fork URL here]

Step 5 (Option a) - Checkout a new Feature Branch (For New Branch in Fork)

Now we have our two remote created, we simply checkout a new feature branch to begin our work.

git checkout -b [Your Feature Branch Name]

Step 5 (Option b) - Pull and Checkout Feature Branch (For Existing Branch in Fork)

If you already have a feature branch in the Fork, we'll need to pull it to our local machine before we begin our work.

git pull origin [Your Feature Branch Name]
git checkout [Your Feature Branch Name]

Step 6 - Rebase Master

Now before any commits are completed, you will need to synchronize the master with the upstream repo and rebase our fork to the latest changes in that parent repo. Since we aren't making changes directly on master anyway in our fork, we will be using the Rebase command, which ignores any changes in master on your PC and will replace it with what is checked out from the upstream repo.

# switch to the master branch
git checkout master
# pull recent updates from upstream
git pull upstream master
# switch back to your forked-based feature branch
git checkout [Your Feature Branch Name]
# rebase the fork's master branch with the upstream master
git rebase master
# push the rebased master back up to our fork living in our fork remote
git push origin master --force

Step 7 - Commit and Push Changes to Fork

Assuming the changes are complete and the above step was completed moments before this step, just commit the code changes you made and push them to the fork.

git push origin [Your Feature Branch Name]

Step 8 - Submit Pull Request

As you return to GitHub or whatever cloud-based git repo you are using, submit your pull request to the upstream owners for their review and inclusion in a future version of their code. It's good form to do this as quickly as possible in order to avoid any chances of significant code changes coming into play before the pull request is reviewed.

---

Update 5/29/19: Adding descriptive/instructional link to rebase step.

Update 6/20/19: Adding Option a and b for Step 5

C#: Sharing a Visual Studio Pro 2017 Project on GitHub

This article will go through and provide a step-by-step guide on how to post a Visual Studio 2017 Project and Solution to a newly established GitHub Repository (repo).  As with many tools, there are a multitude of paths to take and different ways to accomplish a task like this.  This just provides one possible path to accomplish this task.

Step 1 - Add GitHub Tools to Visual Studio

Before we can use GitHub from within Visual Studio 2017, we need to install the plug-in to make it easier to manage.  You can of course just use Git from the command line as well. . . .this article instead looks at the GUI though.
From the Tools menu, navigate to Extensions and Updates.

Once the Extensions and Updates window opens up, navigate to the "Online" item and search for "GitHub".  The "GitHub Extension for Visual Studio" (the one with the official GitHub icon) is the extension you're looking for.  Find it and Install it.  

Step 2 - Configure the Team Explorer

For this next step, I'll assume you have the Professional or Enterprise edition installed with Team Explorer functionality.  Navigate to the Team Explorer if you don't already see it on your screen by going to View >> Team Explorer.

In the Team Explorer window, click on the plug-shaped connections icon to add a new connection to GitHub.

From here, we need to login to GitHub with your GitHub account (just go sign-up for a new account if you don't have one yet). 

Step 3 - Create a New GitHub Repo

Now that you've connected GitHub to your Visual Studio environment, you should see your existing GitHub repos listed in the Team Explorer Connect screen.  For this tutorial, we'll create a new repo for a new project by clicking on the "Create" link and entering some details about the repo in the accompanying pop-up window.

WARNING: you will not be able to mark the repo as "Private Repository" unless you have a paid GitHub Account.  Free accounts are only available publicly for all to see.  Again, just to reiterate. . . .the new repo you create will, by default, be PUBLIC and available for ANYONE to see.

Assuming your create request was successful, you will see a resulting success alert in the Team Services window.

Step 4 - Create a New Solution & Project In the Repo

Now that we have a repo, we can navigate back to the Team Explorer Tab and select our newly created repo to make it active in our work-space.

Once selected, the "Home" subtab inside of the Team Explorer should open and present you with a list of actions you can take with the repo.  Initially, we see that no project has been created or associated with this repo, so we will choose the "New.." link under Solutions.

This will bring up the familiar New Project wizard to allow you to pick your project type and name your project.  For this demo, we will just create a sample web project.

Once created, we can navigate back to the Solution Explorer and see our project exists and source code control icons exist next to each file to denote the status of each file under source control.  By default, Visual Studio includes all relevate source code files but one can add items to be excluded (e.g. add them to the .gitignore) pretty easily later on the commit page.

You should also note, that the toolbar at the bottom of the Visual Studio window now shows a number of Git-related icons that can be interacted with to view edits, make a pull request and select the active branch you are working in at the moment.

Step 5 - Commit Your Work Locally

Git, as an open standard, allows users to work locally on their machines with a copy of the source code in a local repo, and then when satisfied the code is correct, it allows you to commit your changes locally first, then eventually (and separately) commit your code externally to your server or cloud provider.
The first part is committing our work to our local repo hosted on our machine.
In order to do this, we simply click on the pencil icon in the toolbar, or choose "Changes" from the Team Explorer.

Step 6 - Commit Your Code to Cloud

Now that the code has been committed locally, it's time to commit our changes to the GitHub servers.  In order to active this process, we simply choose "Sync" from the Project Explorer to allow Git to see if anyone has already made changes on the server that need to be resolved on our client before posting our changes.  

Once Git has done its job and you have addressed any conflicts, the changes can be "Pushed" to the cloud from the Sync page.

If the push was completed successfully, a warning appears on the Team Explorer like so:

And you can navigate to https://www.github.com/ to see that your project is now accessible in the new Git Repo you created.