Webtuu

Git Basics – Branching, Merging and pushing code to Github

If you’re reading this, you hopefully have a basic understanding of what git is, and you know what purpose websites like Github, GitLab and Bitbucket serve. If you don’t, 😱 fear not! I’ve got you covered 👇.

Prerequisites

In this post, we go a little deeper into using git than my introduction did. Using git can feel scary initially because of how powerful it is, but the only way to overcome this is to practice (in an environment where you can break things!), so – let’s do just that.

Contents

Setup – forking and cloning an existing repo

I’ve put a git repository on Github as a starting point which you can download to save time. Before you download that, let’s start by ensuring you’re in the folder you want to be in.

First, open your terminal and navigate to where you want to place the repo, using the cd command (assuming you’ve read up on command line basics). You might want to create a /code or /playground folder for all your tutorials, like so:-

mkdir code    
cd code     

Next, you want to click fork at the top right of my Github repo page (via the link provided above). A fork is simply creating your own personal copy of my starter code, which you can see in your Github profile. Any changes you make to your fork won’t affect the original repo (unless you merge them in as we do at the end).

On your fork of the repo, click the green Clone or download button

Copy and paste the repository link provided and git clone the repo into your own folder like so (replace your_username)

git clone https://github.com/your_username/git_basics.git
cd git_basics   
git remote add upstream git@github.com:webtuu/git_basics.git

What you have now is one local branch and two remote branches. origin is the remote branch where your fork lives. You can read and write stuff to this remote.
You have also just added upstream – this points to the main project’s GitHub repository. You can only read from this remote.

A “remote” in git, is usually a branch that lives on a git hosting service, or on a server somewhere, as opposed to your local branches.

Nice work! You’ve just forked and cloned a project on to your own device. Give the following commands a try to give you a better idea of what you’ve just downloaded:-

ls  
git log  

You’re now ready to begin some branching work!

The next step is to open up your text editor. You may have a preference for which IDE / Editor you use – mine is Atom, which I can open up from terminal using the following command (from whichever folder I want to open up).

atom .

If you want to set this shortcut up for yourself, you can do so with the following command on Macs (and restarting terminal) – otherwise, just Google “How to open Atom via terminal”.

ln -s /Applications/Atom.app/Contents/Resources/app/atom.sh /usr/local/bin/atom

Notice Atom tells me which branch I am currently in (master) in the bottom right, which will prove useful later on.

Creating your first branch with git branch

Git branches are best explained by example. Every repository starts off with one branch – master. The master branch remains the main branch, through the entire git project. Branches are basically different copies of the same codebase, and allow you to work on multiple different versions at the same time.

A new branch should generally be created for any code change that is to be made to a codebase, like a new feature, or a bug fix.

Say you started a new role as a Junior Developer. Your team has created a blank project template for a new product, and have tasked you with developing a new header for the website.

Your first step is to create a new branch, named appropriately, to isolate your work on the new feature. You can safely develop your work on there, whilst leaving the master branch untouched. If your work is good (perhaps determined by a review from another dev), it’s then fit for being merged into the master branch (usually done on Github if working in teams), and your new code can be made live on your production website.

Let’s pretend we’re in the (realistic) situation above, and give this a shot. To start off, we create our new branch.

Important: Branch naming here is important. Later on, you will be pushing code up to Github, and will want to have a unique branch name to avoid clashing with others. Please follow the convention of using your initials, your birth date (or just a random 6 digit code is fine), followed by /new-header. For example, my branch will be wt210788/new_header

git checkout -b your_branch_name

You should now be in your new git branch – check this by running

git branch

Let’s make some changes now, and commit them!

If you’re using the cloned repo, copy and paste the following code into your index.htmlfile, inside your <body> tags

  <header>
    <img src="https://i.imgur.com/4uM708u.png" alt="Git Basics Header">
  </header>

Hit CMD + S to save your edit in your chosen editor. Let’s view what changes we made with git diff in the terminal (this is useful for when editing many files at once, in a larger codebase)

git diff   

Next, we commit these changes to our branch.

Author/Email Setup

Note: Before making a commit – ensure you have set your name and email address for your commits, mentioned in my Intro to Git (this only needs to be set once)

git config --global user.name "Your Name Here"
git config --global user.email your@email.com

Let’s now stage the file to be committed, and commit it with a meaningful message like so

git add index.html 
git commit -m "Added a basic header with an image"

Use git log again after making the commit, and you will see your commit has been added. Hurrah!

Merging your branch into master

We now have a shiny new header (though admittedly, a very low effort one) to merge into our master branch and get it into production (“production” is the industry term used for live product/website – i.e. where real people will be using it).

Method # 1 – Merging your branch locally

There are two ways to merge this into master. You can either merge the branch with the following code (We recommend you follow Method # 2 for this example, to get practice with Github – if you do Method # 1 first, you won’t be able to do the rest of the tutorial)

git checkout master   
git merge your_branch_name 
git log 

or you can merge it on Github with their web interface below.

Method # 2 – Pushing and merging your branch on Github

The method above is fine if you’re working solo, but if you’re working in a team, you will often push your branch up to Github, at which point it can be viewed by your team and merged into master using the GUI Github provides (there’s an actual merge button, etc.). In short – you’ll need to know how to do both.

Before proceeding – you will need a Github account.

To push code up to Github, use the following command

git branch
git checkout your_branch_name
git push -u origin your_branch_name 

If everything worked as planned, you can now navigate over to the Github page of your fork to see that your branch, with changes, has been pushed up.

Creating a pull request on Github

The final step is of course, getting your code into the main repository. We will do this with a pull request. A pull request in Github’s own words

Pull requests let you tell others about changes you’ve pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.

https://help.github.com/en/articles/about-pull-requests

So, it’s basically where you submit your code for review – and once approved, the PR can be merged into master or whatever branch you want to merge into.

Go ahead now and click Compare & pull request on the page of your fork, shown below

You should then be directed to our main repository, where you can click Create Pull Request and wait for your changes to be merged in.

Feel free to leave your pull request open for others to see, and your branch up on our repo. Changes won’t get merged in on this occasion – otherwise, there will be nothing to change for anyone else working through the tutorial in the future.

If you’ve made it this far – awesome work, and well done. What we’ve covered here should be enough to get you started on your git journey, and using it in your own projects. This part is important – following tutorials can only get you so far. You only really start to learn when you begin to play around with things yourself, so go ahead and explore the world of git!

New posts on Git, coming soon! Sign up for updates below to be notified of when I write more.

Feedback

P.S. If for any reason you didn’t make it to the end of this tutorial – or anything wasn’t clear – get in touch below and I’ll be sure to reply with clarifications. If you struggled with any of it – chances are someone else did too, so feedback is very welcome – it helps me make the tutorial better for others!

Until next time… 😄 👋

Further reading