Branching with Github and VS Code

John J Wisneski
6 min readJan 28, 2021
“Boxing on a Branch” by najeebkhan2009 is licensed under CC BY-NC-SA 2.0

I will get this out of the way first: you should learn how all of this stuff works with terminal commands then switch over to clicking buttons. I’ve had two dictums recently worm their way into my head. The first is not to call something magic just because it is difficult to understand its workings. You need to look past the amazingness of whatever it is that a human was able to figure out and make it work. You do yourself a disservice by putting the any human accomplishment into the realm of the mythical, where you would be less inclined to actually try to work it out.

The second lesson I’ve internalized is that we programmers — and humans in general — are lazy, and that is not always a bad thing. We owe all of society to early man just wanting to be lazy for a change and not have to fight and claw for survival every day. This is a rambling way to support my opening sentence: go struggle with syntax, spelling, fat fingers, constantly checking documentation and youtube videos for how to make branches and committing from the terminal. Then once you have an understanding of what’s going on, switch to pressing buttons and worrying more about the code you are saving than the code needed to save it.

You are ready to start working on a new feature. Last night you were up till three A.M. getting everything back to where it was at 8 P.M. and you resolved to yourself: “Never again, I will start making branches and no longer burden my future self. I have learned my lesson and will not keep everything on main.” As with touching a hot stove as a youth, you sometimes need the pain to learn your lesson. Here’s where to begin in VS Code:

The bottom left of VS Code will tell you the branch you are currently working off of. Click on any part to the left of the “n” in main. This will open up at the top of your screen:

Click on Create new branch…

You will now name your new branch ( here’s a good link for conventions for why to start a branch https://gist.github.com/digitaljhelms/4287848)(here’s one with some conventions on the actual name https://codingsight.com/git-branching-naming-convention-best-practices/) whatever you decide, underscores vs dashes, succinct vs verbose,just know if it is a public repository it will be visible, and if it is a public or shared repo then the entire point is to share information, so try not to make it confusing. Whatever you choose, what was once “main” on the bottom left will be whatever you have chosen, in this case:

You successfully built out the feature or are just pausing for the day and want to push the info to the repository. You’ll now go to the lefthand side of the screen:

The number in the blue circle is the total files that have been changed since the last push. Click on it and you’ll be shown all of those files. On the page/menu showing the individual files, under “Changes,” the possible icons are listed below:

The page with the arrow will open the file into your view and bring you to the first area of change.

The back arrow will discard the changes made to that file so they will not be committed.

The plus sign stages the changes for the push.

As noted on Stackoverflow, the letters to the right stand for:

“A — Added (This is a new file that has been added to the repository)

M — Modified (An existing file has been changed)

D — Deleted (a file has been deleted)

U — Untracked (The file is new or has been changed but has not been added to the repository yet)

C — Conflict (There is a conflict in the file)

R — Renamed (The file has been renamed)”

If you click on the letter a (Working Tree) will open up and show you the changes made in the file additions will be in green and deletions in red.

The arrow and the plus next to the number will Discard All Changes or Stage All Changes so if you are mass adding or deleting you don’t need to click individually. Once you have staged your changes put a description message for this commit, then click the checkmark.

Now down on the bottom next to the name of the branch the refresh symbol will be replaced by a cloud or a number for the current number of pushes to be done:

Click on the number or cloud and :

Now click okay (if you would like to proceed).

Now go to your repository website on Github you will have a message that the push happened so go ahead and click on the Compare & pull request:

You can put in a message about the pull request and if you scroll further down you will see the changes that are being pulled:

In this next screen if you are working with others that need to review the changes before the merge is approved you can put another message for them.

Choose one of these options then click the button again and confirm the merge.

Success! You can now delete this branch if you are done with it.

Now back to VS Code for two more steps. You can change yourself back to the main branch, if you are done with the previous branch you can delete it. To do so, just click on the branch name you just merged…

and select main from the drop-down. To delete the previous branch now that it is merged hit Cntrl-Shift-P

and this will open:

Hit enter or click on Git:Delete Branch

Then click or use the arrow key to select and press Enter on the branch to be deleted. You need to be off the branch you want to delete for it to show up, so change to “main” and you’ll see the branch we just merged.

And that’s it. Reading this post will take longer than actually doing it, and if you do it a few times you’ll wonder why you ever let your time and data be jeopardized by not making branches. Congratulations; we’ve both made it through and there wasn’t a single animated GIF, does this even count as a Medium post?

--

--