For all of this, I’m going to assume that this is a completely new repo and you have no idea how to use GitHub.

First off, we need to create the initial repo. Go to the GitHub main page and click on “New”

Next, fill in all the information about the branch. DigiPen requires that you have a private repo for legal reasons.

If you didn’t checkout “Initialize this repository with a README”, you’ll need to do the command line initialization it gives you on the next page. Just copy the whole command and run it.

Next, you’re going to want to lock down the master branch. This prevents anyone from pushing to master without submitting a pull request and getting approval. Below is a screen shot of a fresh branch with the settings to prevent even the admins from pushing to master without approval (no one is about the law!).

Next, take some time to set up some integrations to help with your code review process. The death of code reviews comes when more time is spent talking about style than function. Let the robots handle style. There’s a bunch of free integrations here. Try some of them out! Many are free for public repos, but some will cost money for private ones or be restricted to one repo.

Before having someone read this blog, the sentence above use to say:

“Many a free for public repos and will code money for private ones.”

Again, code reviews are great and you should be doing them.

Make sure you have continuous integration of some form! I’ve explained it previously, but seriously, make sure you have it! It’s worth all the time it takes to set up.

Next, we want to pull the repo locally.

When I say locally, I mean on your computer. Local changes are changes that only exist on your computer.

To pull the repo, go to the main page and copy the link under Clone or Download.

In a command line, type git clone REPO_LINK where REPO_LINK is the link you just copied.

By default, you’ll be on the master branch. This is where your working game should be. This should never, ever be broken. If it is broken, it should be immediately fixed and those who pushed the code shall have a sign that mocks them placed just behind their keyboard.

We don’t want to be on the master branch locally. Because we locked down the master branch, we can’t push to it from here. Instead, we use the command git checkout -b BRANCH_NAME to create a new branch. In this case, I’ll call mine AwesomeBranch.

Now, let’s write some terrible code.

int main(char**argv, int argc) {
    std::cout << "Main Function" << std::endl;
}

Perfect. I put this in a file named main.cpp. If we want to push this, we need to open a command prompt in the folder containing the hidden .git file.

If you don’t see the .git file, you don’t have hidden files on. Do yourself a favor and type “hidden” into the search bar for windows. Show Hidden Files and Folders will pop up and you can make it look like the screen shot below. Show hidden folders and don’t hide extensions. Do this for any computer you interact with until the day you die.

Type git branch first. It should have AwesomeBranch highlighted green and master branch just below it. Next type git push -u origin AwesomeBranch. This tells GitHub that you’ve created a branch locally and want it to exist on GitHub.

Let’s look at the files. Type “git status”. If you created the file, it should show a red “main.cpp”:

That file is currently untracked. In short, it’s a file that GitHub won’t try to merge with anything else. For now, it’s good enough to leave it at that and we’ll get into it more later. To add that file, use git add main.cpp. Alternatively, you can use git add *.cpp to add all files that end in .cpp.

That file is now tracked. We’ve told GitHub that this is a file we may want to add to a commit. Next, we need to package that file into a commit under a commit message. This allows us to push it and later possibly revert it.

To do that, type git commit -m “SOME MESSAGE”. Try to be descriptive. You might be searching through your commits to find one so you can roll back your changes if something breaks!

If you forget to type -m “SOME MESSAGE”, you’ll open up Vim. Relax. Everything is going to be fine. Hit I to turn on text editing mode so you can type your commit. Hit escape to exit text editing mode. Next, type :wq to save and quit. Yes, it really is :wq. The colon puts you in command mode. w tells it to save. q tells it to quit. Some people actually like this as a main method of writing code.

Try typing git status again. You should see something like this:

When we commit, we can see that we added a file with three lines and main.cpp was tracked for the first time. When we checked the status, we see that we’re 1 commit ahead of origin/AwesomeBranch. That simply means that we have a single commit ready to push to AwesomeBranch.

Just as it hints, we’re going to type git push. This pushes our commit to AwesomeBranch so they’re synced up.

If we immediately go to GitHub, we should see this:

The yellow bar is a nice shortcut that lets us quickly create a pull request. While that’s great, it’s good to know how to do a pull request if that doesn’t show up. Click on Pull Requests at the top.

Click on New pull request.

By default, the base and compare branch will be master. Base is where your changes are trying to go to. Compare is the branch you wrote code for. The arrow isn’t lying in the picture below.

We can see our changes show up now:

Click Create pull request to get a few more options to show up.

Make sure to write a comment for what it does. You can even include pictures if it helps. I also recommend creating some custom labels to help reviews know what they’re in for. Does the code review require graphics knowledge? Make a tag. Is the code less than 10 lines? People will be more willing to review it quicker if they see a tag that says that. Is this time sensitive and vital? Make a tag for it.

People are lazy. If you hint to them that this review is important or small, they’re more likely to do it right away.

Click Create pull request once more and the pull request is up and ready to go!

While in the pull request, click Files Changed to see the changes.

Now we can start to review the code! Click on the + sign right in the code to leave comments on it directly:

When writing comments, avoid “You”. It’s not “You forgot to put this in”. It’s “This is missing this”. It’s very easy to accidentally offend someone. Remember, you’re basically reading their journal on a whiteboard. Be nice. Be clinical. Be helpful. You’re a team in this.

It’s also important to be brave. Whenever you comment, someone is wrong. They might have made a mistake, or you think something is a mistake. Either way, someone needs to be corrected. If you aren’t sure, it’s good to leave a comment saying you aren’t sure.

When you write one of those comments, make sure to click Start Review rather than Add Single Comment. Add Single Comment will send notifications out to any webhooks you’ve set up (such as a Slack integration!). Start Review will only send that notification when you’ve finished the review:

Again, remember, you’re a human. Look for logic errors. Look for better algorithms. Look for missing keywords. Don’t look for style! Let the robots do it!

Once you’ve finished making comments, you can click Review Changes and submit them back. After you’ve gone back and forth with changes and comments and the pull request is read, you can approve the pull request and submit it to master.

This example doesn’t have continuous integration or any special checks, but they would show up here when the pull request is first created if they existed.

Congratulations. You now have standards and a soul. Welcome to your first step towards being a professional programmer.

Unfortunately, just sitting in front of someone else’s code and telling them what you don’t like isn’t enough. There’s a bit you have to know to make sure you’re doing them well. Let’s talk about it.