SideStories IIX: GitHub, Git and Terminal

The how-to on Git with the Mac’s Terminal

Hugh Burgess
The Startup
9 min readOct 3, 2020

--

EDIT: This article has been updated February 2023.

Overview

Okay so today there was no main lesson as I have been focussing for the most of the day on understanding how GitHub works, and more importantly how it can be used through a local server, in my case, on Terminal on my Mac.

Oh man, how can I explain this. I have learn’t today how to pull a clone of code, a remote repository (shorthand as “repo”, that could be actively modified and built by several devs), then edit that code locally (on our own computer, not on the GitHub site) and then send it back into the main code and save those changes so the main code is then updated. I love it!

Jumping In

Think about it, any program you see has most likely been made by several developers who need to edit and add separate parts of the main code locally, then join all those updates together. This is essentially what GitHub is about. I have been on Google all day so you don’t have to, I’ve boiled everything I learn’t down into a page of code in a notebook. Let’s go through it step by step.

Creating a Branch using Mac’s Terminal

Here’s a little picture from GitHub’s Guide for the visual learners out there like myself to show you that process:

- from guides.github.com

So what are we looking at here today? This is the process of making a branch off the main code workflow, making edits locally and merging it into the main code with the updates we have made, which in turn updates the main code itself.

But first, let’s take this step by step using Terminal (for Mac), doing this locally (on our own server, computer) not on GitHub.com. That would be too easy.

Step 1: Set up Git Account and Initiate Git

Okay so first we have to register ourselves into the Git system to use it. Sign up to GitHub.com and create an account then click here to download Git into your Mac to use on Terminal.

Once you’ve got an account on GitHub, follow their instructions here on how to create a repository (repo) and start it with a README.md file. This file allows for other developers to get a good overview of what the project is about. Don’t worry, you can leave the file blank/minimal for now. We’re going to add and edit it later as the project becomes clearer.

Once Git is loaded on your Mac, go onto Terminal and type:

Here we are assigning your name and email to your git logs, it adds security and an identity on Git.

Afterwards you can check your information is registered by typing:

Next we type out this command in Terminal:

This will initiate Git to track your files in the project and from then on when you type a command starting with “git” you are referring to that system.

Step 2: See the Overview on your Working Directory

Let’s look at what we’ve got in our directory as it is. Type:

This means “list files” and shows us the files in our directory. This could be Pictures, Applications and so on. If you want to see all files including hidden ones, type:

Step 3: Find the right Remote Repo URL

Lets fetch (without merging) the origin branch in our remote repo. If we type:

This will show us the details of the Remote Repo (the origin) in Terminal, and give us something like this:

remote: Enumerating objects: 12, done.

remote: Counting objects: 100% (12/12), done.

remote: Compressing objects: 100% (5/5), done.

remote: Total 10 (delta 3), reused 6 (delta 2), pack-reused 0

Unpacking objects: 100% (10/10), done.

From https://github.com/username/remote_repo_title

3d664fc..9c9e0ff master -> origin/master

You’ll notice near the end there we got a URL. I’ve altered the username path and the destination name for privacy but this is the URL we want to copy and paste in the next step.

Alternatively, if you go to the project folder in GitHub, there is a “<> Code” button at the top of the project, click on it and you can copy the file URL path for the next step.

Step 4: Cloning the Repo into the Working Directory

Okay so we see our files in our local directory, but we have no remote repo listed in the files, so we need to import it by cloning a copy of the repository we made earlier in GitHub.com, to bring the repo into our local server, this is done using this line of code in Terminal:

This is the address example that you can paste in from Step 3, then add “.git” on the end (or use the button mentioned above in GitHub to get this line in full). This will then install a clone of the remote repository into your working directory, if you then type “ls -la” again you’ll see your new repo clone included, git will flag these new changes also as untracked changes, in this example, “remote_repo_title/”.

Step 5: Focus on the Repo

Terminal is incredibly useful for moving around our files by commands, and we can move in on that new clone file by typing:

ls -la

cd remote_repo_title/

What we just did here was navigate to the overview of the files we have including hidden ones, then changing directory (“cd”) to the remote repo, whatever it’s name is. Now that we are in that clone file directory, type “ls” again to view it’s contents. It should show you the README.md file you created earlier (in Step 1) on GitHub. If you don’t have one yet you can easily type touch README.md to create one. Then type:

This opens the specific file within the directory that we want to modify or edit in a text editor, I’d recommend using the free downloadable IDE (integrated development environment) Atom as one, or Visual Studio Code.

Step 6: Edit/Update/Add Changes to your Code

This is the part where you make the changes you wanted to your code in a text editor/ IDE of your choice, as I said I prefer VSC or if you want to use a text editor with a console to view what the user will see, I highly recommend repl.it where I like to see the changes as I code by pressing cmd+Enter as I work.

Step 7: Check Status of the Repo

Next, let’s see the current state of our master branch, which we are currently on. This is also a good command to use whenever we’re a bit lost and need to see what branch we’re on, or what files are untracked/committed/changed etc:

This pulls up the following information for me, notice that it says how the README.md file is now modified because we edited it in our text editor (Step 6).

On branch master

Your branch and ‘origin/master’ have diverged,

and have 1 and 2 different commits each, respectively.

(use “git pull” to merge the remote branch into yours)

All conflicts fixed but you are still merging.

(use “git commit” to conclude merge)

Changes to be committed:

modified: README.md

Changes not staged for commit:

(use “git add <file>…” to update what will be committed)

(use “git checkout — <file>…” to discard changes in working directory)

modified: README.md

Step 8: Commit and Add Changes to the Staging Field

- from guides.github.com

So we’ve written our updates and now we want to move that updated file into the Staging Field to prepare to commit it back into the master branch (see the visual example once again, above).

Let’s first create a branch off the master branch and call it “feature”, the same name as the visual example:

git switch -c feature

This creates the branch feature, which diverges off the master branch (e.g. where all the other devs on this project are submitting their work as well). Essentially we are creating our own personal branch to input our updates and re-submit into the main code again. It’s my personal preference to use switch -c which creates and moves over to that new branch.

Next we are going to commit our changes/updates to the feature branch:

git add .

git commit -m “Here are the changes I made..”

So first we added all updated files to the directory (called “.”), and then we commit those files with a message (-m) and type a message so that other devs can see when browsing on the remote server a short summary of what changes you have made.

Step 9: Pushing the Branch to the Remote Repo

To do this, type:

git push -u origin feature

Note: We are pushing upstream (shortened as -u) to the “origin” which is the remote repo and the “feature” is the exemplar name of the branch we are currently working with, and will thus be created remotely also.

Step 10: Pull and Merge the Feature Branch to the Master Branch

Let’s switch over to the master branch.

Imagine you are on a boat (the feature branch) heading towards the dock (the master branch) and you throw a line of rope to the dock, then you hop onto the dock and pull the boat in (the pull) with the rope and tie the boat to the dock (the merge). That’s kinda what we’re gonna do, we have to change branches to pull the feature branch in:

git checkout master

Now we are in the master branch, let’s type the command to pull in the master branch from remote, which updates the branch itself, so our remote and local master branches are equal, then we merge our new feature branch to the master branch:

git pull origin master

git merge feature

This means now that our local master branch has the updates created in the feature branch, and is ahead of the remote master branch now, so we have to push this to remote.

NOTE: It’s considered good work ethic to NOT push to master remote branches, better to work with these merging steps remotely, where the new branches are reviewed by peers in a Pull Request, and then merged safely, updating the master branch remotely. For sake of explanation and understanding, let’s continue.

Step 11: Push Changes to the Remote Repo

Now that we have our updates merged with the local master branch, let’s “push” them into the main code remotely, the main stream of the workflow in the remote repo:

git push origin master

Step 12: Delete the Local and Remote Branches

So now the updates are integrated into the master branch, which can be viewed in the remote repo by other developers, we can safely delete the feature branch, as it is now irrelevant and served it’s purpose. Make sure you are not on the branch you want to delete.

I’m a bit OCD so I looked up how to view and delete all the feature branches, both local and remote:

  • Delete the local feature branch:
  • Delete the remote feature branch:

Then if you want to view what’s left of the branches, local and remote, type:

If your git shows you branches remotely which you know are already deleted after Pull Requests and are dead branches, there’s a handy line which can “prune” dead branches, this means we do a fetch to see new updated information of what branches in remote are still active, the dead ones are marked as deleted and no longer tracked:

git fetch --prune

Finally, type “git status” to reveal the current state your branch is now in. It should say something like:

On branch master

Your branch is up to date with ‘origin/master’.

And that’s it!

You’ve successfully created a branch on a local server, added updates, and merged it back into the remote repository on GitHub. Kinda cool huh? Imagine this on a bigger scale, with several devs doing the same thing for the same main code at once. Pretty exciting!

See you next time.

--

--