loading...

BREAKING INTO WEB DEV – THE NO JARGON GUIDE – ARTICLE 1 - GIT & GIT HUB

lauracharvey profile image lauracharvey ・16 min read

image of pc screen show github homepage

Table Of Contents

INTRODUCTION

Breaking into the tech industry as someone over the age of 25, who didn't study computer science in school was intimidating.

I’m 29 years old, the extent of my ‘tech’ education in school was building a website using PowerPoint – yes – you read that right – PowerPoint.

I bumbled my way through life, knowing tech was something that I was interested in but that I always thought was out of my reach.

If you are reading this and you are feeling like I was, I am here to tell you…

TECH IS FOR YOU! And I am on a mission to help you make the best start.

ABOUT THIS BLOG

Welcome to my blog – a series of articles for newbies aimed at explaining things that I found challenging in very plain English so that they will be a breeze for you (hopefully).

As a newbie I often found the guides I am reading have this element of tech "stuff" I am just expected to know about. They all seem to assume prior knowledge or knowledge around the subject so I created this blog to help guide you through the things I found tough.

I am open to feedback so please, leave me some below or reach out to me on Twitter. I am also keen to cover the topics that you will find most useful so if you have got a burning question/worry get in touch and I will try and include it in this series.

This is article 1. I ran a poll to get an idea of which topic to cover first, the vote came out as:

  1. Git/GitHub
  2. Hosting/Domains
  3. What even is Web Dev? (this will be an overview of the industry, roles, languages, working options etc.)

Just so you know what will be coming up next 😊

A couple of notes for the reader

Navigation - you can read this guide all in one of use the contents list above to jump to the sections you need.

This is a complete beginners guide to Git/GitHub: setup, creating your first repo and pull requests (don’t worry newbies, stick with me, we will go over this), it is not an extensive manual so if you’re looking for more extensive material on Git/GitHub can I suggest you check their documentation here: https://guides.github.com/.

This guide assumes you have an interest in Web Development and have started learning to write code in some form.

I have tried to explain everything very simply, if you feel patronised, I’m sorry but as someone who found other guides too technical, I wanted to try a no jargon approach.

My instructions are for setup in Windows – if you are a Mac/Linux user and the setup differs greatly, please can you share the instructions with me so I can add them here. Thanks 😊

Ok if you are still with me, lets dive in.

THE REAL JUICY STUFF…

LEARNING OUTCOMES

By the end of this post, I hope you will be able to:
• Understand what Git/GitHub is
• Understand why you might want to use it
• Know how to set up Git/GitHub
• Understand what a repo is
• Know how to create your first repo
• Know how to clone someone else’s code and create a pull request

WHAT EVEN IS GIT/GITHUB?…

Git and GitHub are not the same thing, but they are partners in crime.

Git is a version-control system that is downloaded to your computer, it monitors code files that you/others have written and keeps track of any changes you or other developers make to those files. It’s particularly helpful if you are working on a project with multiple people, it allows each developer to have a copy of the code file and the history of that file on their own PC/laptop so they can make changes on their own version before merging it with the master copy.

GitHub is a public storage space for those files and allows easy access to the code files for anyone who wants to see them/work with them. It also allows you to access other peoples code if you want/need to.

BUT “WHAT IS VERSION CONTROL” I HEAR YOU CRY?

As you progress with your learning of programming languages and your confidence with projects grows, you might choose to move away from online code editors like CodePen where you essentially type all the code that would normally appear inside the "body" tags and switch to a software-based development environment like Visual Studio Code.

Software-based Development Environments – often known as Code Editors or IDE's (Integrated Development Environments) are software that you can download to your computer, these work like offline coding ‘pens’ where you can write and debug code on your own laptop/PC. You can also download extensions that make writing code easier. I will cover Code Editors/IDE's and file setup in a later post so keep your eye out.

Generally, to get started with a project in you need to create ‘files’ such as:

style.css
index.html
script.js

These are the files that contain your (source) code.

Now, fast forward 12 months, imagine you are building the new hottest app (I have great faith in your abilities 😉). You have published version 1.0 to the app store and sales are going well, but, to fix bugs and stay competitive you want to update the original code.

While updating the code, you hit a skills gap, however, you are aware your buddy, knows something about the issue you are facing so you send the file to her. She takes a look, adds some code and sends the file back to you. You accidentally overwrite the existing file and the app stops working.

How do you get back to the original?

How do you know which change it was that caused the error?

That is where version control and Git come in. Git keeps the original source code at the heart of your project and tracks all changes made to that code by you and your pal, so should you need it; you can roll back to earlier versions. It also allows multiple people to work on a file at the same time and merge the separate changes without causing issues to bring together one updated file – i.e. version 2.0 of your app (and so on).

I’M NOT BUILDING AN APP – WHY DO I NEED IT?

Git/GitHub are very widely used in the industry, here's a list of the benefits:

  • If you are considering transitioning to a career in Web Development, it is a good place to showcase your code to potential employers
  • It shows these same employers that you are confident to have your code in a public space
  • You can host/publish your portfolio on GitHub
  • It shows you have an understanding/appreciation of version control
  • It shows you can use industry specific tech
  • It puts your work out there so other devs can see it, improve on it and potentially coach you on how to make it better
  • If you want to contribute to Open-Source projects (I will cover these at some point too) you can access them on GitHub
  • It allows you to track changes you make to your side projects and therefore, track your progress

OK, SO FAR SO GOOD, HOW DO I GET STARTED?

First things first, you will need to download Git. You can do that here:

Windows: https://git-scm.com/download/win
Mac: https://git-scm.com/download/mac
Linux: https://git-scm.com/download/linux

I (Laura) have Windows so my instructions are for installation/set up with Windows – as I said up top, if you’re a Mac or Linux user and the setup is very different please let me know so I can include it.

Now, I am not a tech expect or even remotely expert with Git/GitHub, so I opted for all the standard options during the installation process. Unless you know differently, I would suggest you do the same (just click next a bunch of times until it finally says finish).

Next you will need an account on GitHub, you can sign up here: https://github.com/

Please don’t get disheartened once you open GitHub, it looks terrifying, but I will take you step-by-step to set up, adding an existing project to GitHub, accessing/viewing other peoples projects and contributing to them.

SETTING UP GIT/GITHUB

Git is controlled by the ‘Command Line’ on your computer, sometimes referred to as: cmd, cmd.exe or Command Prompt. If you don’t know, the command line is the black box with white text you sometimes see pop up when installing/uninstalling new apps, it looks like this:

a screenshot of a Microsoft Windows command line

If you are a Mac user you can go directly to your command line however, with Windows you will need to use GitBash.

When you downloaded Git, GitBash should have been included you can access it by pressing the Windows key and typing GitBash or by searching in the search bar.

screenshot of windows search bar

Once open the screen will look something like this:

a screenshot of GitBash

First you need to introduce yourself to Git, go on, make friends, you’re going on a long and fruitful journey together after all!

Give Git your Username & Email by typing the below after the $ on each line:

  1. git config --global user.name "YOUR_USERNAME"
  2. git config --global user.email "INSERT_YOUR_EMAIL_HERE"

To check that these details have been saved, type:

git config --global --list

Press enter and you should see something, a little like this:

screenshot of GitBash with username and email added

Now Git is ready so you need to create a repo in GitHub – ready for it to receive your files.

BUT LAURA - WHAT ON EARTH IS A REPO?!

A repo (more formally known as a Repository) is basically a container within Git/GitHub where your files will be stored. There are two types of repository: your local – the one on your computer and your remote – the one on the server - I like to think of it as the one in GitHub.

Inside a repo, you will find source code files, other files related to the project like sound bites, images and a README file which basically explains the project and should act as user guide (if necessary).

A repo looks like this:

screenshot of a github repository

You can create one easily by clicking on the ‘cat icon’ in the top left of GitHub to get back to the home page and then clicking the “New” button next to Repositories.

screenshot how to create a new repository in github

2nd screenshot of how to create a new repository in github

Give your repo a name, the description is optional, decide whether to make it public or private and then click “Create repository”. No need to create the README file at this stage, we will do that later. You can leave gitignore for the time being too.

Your new repo should look a little something like this:

screenshot of what a new repo looks like

That’s it! Keep it open while we walk through linking your files.

SO, HOW DO I GET MY FILES INTO THE REPO?

First, let’s talk a little bit more about how files are moved between your computer and GitHub.

We can refer to this as the “Git workflow”, there are four main elements:

Working Directory (the folders on your computer)
This is like a library of all your files, you need to access the correct folder (working directory) to control the files you want to change/upload

The Staging Area (the in-between)
This is where you can save files that you have been working on locally before you are ready to move them to your repository. It is like saying, I think these are the files I want to upload but I am not too sure, hold on to them for me and I will decide what to do with them later.

Staging is useful because it means you don’t have to send every single file in a folder to your repo, it allows you to just move the files that you want to upload

Local Repository (on your computer)
Your repository (folder/box/container of files) on your PC where your files are stored and only you have access to

Remote Repository (GitHub)
Your repository that is held on the server (online/remotely/not where you are) and can be accessed by anyone – in other words your GitHub repository.

COMMON GIT COMMANDS

There are various commands (all typed into GitBash) to tell Git what to do with your files here are the ones you need to be aware of at this stage:

cd Desktop/FolderName – this tells the command line which folder (directory) on your computer you would like to send into the git workflow – we will work through an example of this later

git init – think of this as initializing or starting off the process. If you want to do anything with git you need to include git init. It turns the folder from a normal folder to a Git folder – one that Git has access to

git add – this moves your files into the staging area

git commit – this moves your files from the staging area into your local repository (the one on your computer)

git push – this copies your files from the local repository (the one on your computer) and sends them to the remote repository (the one of GitHub)

git pull – gets files from the remote repository (the one of GitHub) and puts them into the working directory (your library of Git files).

git status – tells you the status of your files - where they are sitting and what you have done to them

git clone – allows you to copy other peoples files from GitHub to your local repository (your computer)

OK, SO CAN I PUT THE FILES INTO MY REPO YET OR…?!

Yes! Here goes, a step-by-step guide, how to add an existing project of your own to GitHub.

1. Tell Git where to look

Open GitBash and type:

cd followed by a space and then the actual file path

So, if your project was stored on your desktop under a folder called “project” you would type: cd C:\Users\yourname\OneDrive\Desktop\Project

2. Create your README file

Type:

touch README.md

You can edit this README file in GitHub later

3. Start the process

Type:

git init

GitBash should then think about it for a second and give you an initialization message and label this folder the “master”.

4. Add files to your Staging Area

Type:

git add .

Don’t forgot the space followed by a full stop after add, this means “all” and will ensure all files in the selected folder will be marked for action in the staging area

If you only want to add certain files you can do so by:

git add followed by a space and then the filename

5. Check the status of your files

Before moving forward, you might want to check which files are in the staging area. You can do this by checking the ‘status’. Type:

git status

It will list all the files in the staging area

6. THE SCARY ONE

Type:

git commit -m “your message”

Sends all your files to your local repositories. The -m “” is simply included for you to be able to add a message with your commit i.e. “first commit” or “commit with bugs fixed”

7. Set up the link between your local and remote repository

In GitHub, open the repository you created

At the top of the Quick setup section, you should see a URL

screenshot of quick setup in github

Copy this to your clipboard (CTRL & C)

Now back in GitBash type:

git remote add origin paste the url here

You will probably have to use right mouse click + paste as CTRL & V doesn’t seem to work with GitBash.

8. THE REALLY SCARY ONE

Type:

git push origin master

This copies or ‘pushes’ the files from your local repository (your computer) to your remote repository (GitHub) i.e. makes them visible and available on GitHub you need the “origin master” to tell which branch in GitHub to update (more on this below).

9. DO A VICTORY DANCE!

You just pushed your first repo to GitHub – you’re now a fully-fledged Web Developer 😉

YES! I DID IT! BUT WHAT DO I DO NOW?!

You can make changes to the code files on your computer, save them as you normally would and then in GitBash:

  1. git add . (add your updated files to the staging area)
  2. git status (double check the status of your files)
  3. git commit -m “second commit – bugs fixed”(commit to local repo)
  4. git push -u origin master (-u stands for “update”)

Code and repeat…that’s all there is to it!

GOT IT, BUT HOW DO I ACCESS OTHER PEOPLES CODE?

Find a project you want to contribute to or look at on GitHub. You can test using my rock, paper, scissors game if you would like to.

Link here: https://github.com/lauracharvey/rockpaperscissors

• Open the repository for the project you are interested in
• Fork It

screenshot - how to fork a repo

In the top right, under you profile picture there is a Fork button, this creates a copy of the remote repo on your own GitHub.

• Click “Code” in the top right-hand corner of the main body

screenshot of completed repo

• In the dropdown, select the repo URL, copy it to your clipboard

• Now go to GitBash and type:

cd your file path

Where your file path is replaced with wherever on your computer you want to store the new files.

• Then…

git clone followed by the full url copied from GitHub

example: git clone https://github.com/lauracharvey/rockPaperScissors

• Finally...Code 😊

You can make changes to your local copy of these files however; you cannot upload them to the other persons remote repo yet.

In order to do that, you first need to create a branch of the code and then create what is known as a “pull request”.

HOW DO I ADD CHANGES I MADE TO ANOTHER PERSONS REPO?

TAKE A DEEP BREATH

So…Git/GitHub are set up in a branch system, imagine a tree with 5 branches, and 2 woodpeckers who live on that tree, woodpecker A pecks on branch 1 while woodpecker B pecks on branch 2. Both branches belong to the same tree (the master tree) but they can both work at the same time on these different branches, woodpecker A does not have to stop to allow woodpecker B to do their work.

Lets, bring that back into the context of Web Development – Developer A & B are both working on the same project – for arguments sake, let’s say a rock, paper, scissors game.

Developer A finds some bugs and wants to fix those bugs so starts working on them on his computer.

Developer B wants to work on some new features of the game but he’s in a hurry and doesn’t want to wait for A to fix his bugs.

With Git/GitHub Developers A & B can have their own version (branch) of the project on their own computer so they can both work at the same time, once they have finished their coding, they can commit/push those changes to their branch without impacting the master file (the tree).

Once they have agreed on the changes, they can then agree to update the master file that is stored in GitHub.

The first steps in creating a pull request are:

1. Check you are in the correct repository

cd followed by a space and then the actual file path

So, if your project was stored on your desktop under a folder called “Making-Code-Better” you would type:

cd C:\Users\yourname\OneDrive\Desktop\Making-Code-Better

2. Create your branch

Type:

git branch branch name

Make sure you give your branch a descriptive name, so it means something to everyone working on the project i.e. branch-to-fix-bugs-in-version-1

3. Make sure you tell Git to open the new branch by using checkout

Type:

git checkout branch name

You should then get the following message:

Switched to branch ‘branch name’

You can use git checkout at any time to move between branches, you use the command git checkout master to move back to the master file.

4. Add updated files to your local repo (still on the branch).

Type:

git add .
git commit -m “updated a typo in README”

5. Add these changes to your forked repo in GitHub

Type:

git push --set-upstream origin branch name

This is just like a normal push but you are making sure you push to the branch instead of the master file

6. Go to GitHub and get ready to make a “pull request”

MAKING THE ACTUAL PULL REQUEST

If you've jumped ahead to this section, you need to read the above steps to set up a branch from the original repo before creating a pull request.

If not, here are the steps for creating one:

  1. In GitHub – open the forked repository (your copy)
  2. Click “New Pull Request” on the left-hand side
  3. Select the original repository on the left and your forked repo on the right
  4. You should see an alert notifying you that the branches can be merged – this means there is no conflicting code
  5. The original creator will be notified and can decide whether to accept your pull request AND you’re done – you’re up to speed with Git/GitHub…3000 words and possibly a very tired brain later. Well done!

CONCLUSION

I really hope this guide helped you understand the steps needed to master your first experience with Git/GitHub without being bowled over by jargon.

If you have any questions or there is something I have not explained clearly, please drop me a comment.

As explained in the intro, I would like to do a series of these guides so comment or reach out to me on Twitter if there is anything, you would like me to cover.

I have loved putting this guide together so please, give me more things to write about! 😊

Posted on by:

lauracharvey profile

lauracharvey

@lauracharvey

Aspiring Web Developer from the UK. I started coding in May 2020 and have so far studied and built projects with; HTML, CSS & JavaScript. I am keen to help so never be afraid to reach out :)

Discussion

markdown guide
 

First Article got the git badge! Congrats, thats no easy feat. Well done

git badge

 

Thanks! I’m very proud of my Git badge!

 

Wear it with pride! It was well deserved!

 

Nice article Laura! Only suggestion I have is that you could just past the code from the terminal into a tool like carbon.now.sh and make those screenshots prettier. e.g. dev-to-uploads.s3.amazonaws.com/i/...

 

Thanks so much I'll have a look into that :)

 

Hey Laura, great article. Minor things. When you do Cd (Change Directory) it usually is backslash like cd C:\myfolder. With Git Add . you are showing how to add all the files that are "untracked". You can also show Git Add "filename" - to only add certain files. Other things to bear is how can you create a Git Repo on Github, and then add local files to the staging and then push the items to remote. You must tell git where is the remote repo. Also, Git works by a way of messages - ie. messages or comments are important, so that's why when you commit, a comment is needed. The good practice is to ensure comments are present actions, so instead of "added config files", should be "adds config files". It is more useful when you look for any issues in the repo and the message are present tense. There is also the git log message to view history of your commits and where your current branch is. These are just pointers. I think your article is impressive. Enjoyed reading it.

 

Thanks for the feedback 😁

 

As someone new to web development(started 2 months ago), i find Git/GitHub scary as I never knew how they work... I must say, I'm lucky to come across this post😊as it relieves me from my fears and anxiety of understanding Git/Github... I'll definitely try to push this project I just completed to GitHub following the steps you highlighted. Thanks!

 

Yay!!! I love this! So glad you found my guide and really hope it helps you creating your first repo. Any questions please get in touch 😁

 

Hey Laura, if you don't mind, I have a dumb question to ask:

  • I just completed a project and I'd like to push it to Git/GitHub, which of the project files is meant to be pushed-- the HTML file, CSS or both ??

Hey!! There are no dumb questions 😁 all the files related to that project that are needed to make it work or needed for someone looking to fork it should be added/pushed 😁

Thank you Laura... How do I go about a situation where I have my HTML files in the parent folder and my CSS and JavaScript files are inside subfolders (Stylesheet folder and script folder) in the parent folder...

Can I target the respective files I want to push to GitHub without pushing my whole project folder as it contains other files, like this?:

C:\Users\yourname\OneDrive\Desktop\Project\index.html

C:\Users\yourname\OneDrive\Desktop\Project\StyleSheet\main.css

C:\Users\yourname\OneDrive\Desktop\Project\Script\demo.js.

-If your answer is yes, can I push them at once or I have to push the files three times considering the fact that they are in different subfolders.

Thanks always!!

Hmm that’s a toughy! Do they need to be in seperate folders? Or could you have all 3 files that you want to push in the same folder? If you want to keep them seperate that’s fine I think you would need to do a push for the parent to a new repo and then you can create sub folders to that parent repo! 😁

 

I started reading this looking for the moment I say: "screw this. I don't get it".

I'm surprised by the simplicity. Extremely helpful for a newbie like me, which English is not the first language.

Made my day. Thank you.

 

Yay! So so glad! That’s exactly how I felt trying to learn Git/GitHub so really pleased that my guide helped you understand! Thanks for reading 😁

 

Really helpful and well thought out post! I will definitely be using this as my guide. So many of the other tutorials and courses just expect you know what they are talking about.

Thanks so much Laura.

 

Glad I could help! If you get stuck with anything! Give me a shout 😁

 
 

Hi Laura
Nice starter article for beginners. I'm also new to Git/GitHub and this one question I always have 'Do I need to create PR to push to my own repo?'

 

Hey Bijay
Thanks so much for reaching out. Can you just confirm what you mean by PR? I’m not familiar with the abbreviation.
Thanks
Laura 😁

 

Ahh I understand now! Thanks for clarifying 😊 no need to create a pull request to add to your own repo. If you go to the section called “What’s Next?” In the article the instructions are there for adding/updating to your own repo.

1 git add .
2 git status (not necessary but good to check)
3 git commit -m “message”
4 git push -u

😁

 

A great and very detailed article, Laura!
A few notes which might be useful:

  • In Bash, Shift+Ins combination is used for inserting. However, when using git through VSCode terminal, Ctrl+C works fine
  • You can shorten 'git push -u origin master' to 'git push' for updating
  • There is a shortcut for creating a branch and moving to it - git checkout -b branch-name
 

Thanks for the detailed feedback that’s really helpful 😁

 

This an absolutely fantastic read. I'm a passionate but still very wet behind the ears git user. You cover the basics and then some in a thorough but still easy to follow manner. Thanks for sharing!

 

No worries at all! Glad you enjoyed it 😁 I think I’ll do a bit more on git later in my series so keep an eye out 👀

 
 

Congrats on your first post! Looking forward to your next one!

1st place in Mariokart

 
 

This article is amazing. Thanks for sharing it!

 
 

Thanks for this...was really clear and easy to understand👍

 

No worries at all! Glad you found it easy 👍😁

 

This is amazing, saved me so much time googling jargon I didn’t understand.

Can’t wait for more of your blogs!

 

Thanks for leaving your feedback and so glad it helped 😁