Table Of Contents
- Introduction
- About this Blog
- Notes for the Reader
- The Real Juicy Stuff
- What Even Is Git/GitHub?
- What Is Version Control and Why Should I Care?
- How Do I Get Started?
- Setting up Git/GitHub
- What Is A Repo?
- Common Git Terms
- How Do I Add my Files to my Repo?
- What Next?
- Accessing Other Peoples Repos?
- How do I Add Changes I Made to Another Persons Repo?
- How do I Create a Pull Request?
- Conclusion
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:
- Git/GitHub
- Hosting/Domains
- 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
UPDATED 12/08/2020
Git & GitHub are slowly updating their terminology from master branch to main branch so this article has been updated to main throughout except in the instructions where you will still need to use master.
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 main 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:
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.
Once open the screen will look something like this:
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:
To check that these details have been saved, type:
Press enter and you should see something, a little like this:
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:
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.
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:
That’s it! Keep it open while we walk through linking your files.
So, how do I get my files into my 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 my files in 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:
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:
You can edit this README file in GitHub later
3. Start the process
Type:
GitBash should then think about it for a second and give you an initialization message and label this folder the “main”.
4. Add files to your Staging Area
Type:
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:
It will list all the files in the staging area
6. The Scary One
Type:
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
Copy this to your clipboard (CTRL & C)
Now back in GitBash type:
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:
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 main” 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:
- git add . (add your updated files to the staging area)
- git status (double check the status of your files)
- git commit -m “second commit – bugs fixed”(commit to local repo)
- git push -u origin master
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
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
• In the dropdown, select the repo URL, copy it to your clipboard
• Now go to GitBash and type:
Where your file path is replaced with wherever on your computer you want to store the new files.
• Then…
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 make changes 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 main 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 main file (the tree).
Once they have agreed on the changes, they can then agree to update the main file that is stored in GitHub.
The first steps in creating a pull request are:
1. Check you are in the correct repository
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:
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:
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 main to move back to the main file.
4. Add updated files to your local repo (still on the branch).
Type:
5. Add these changes to your forked repo in GitHub
Type:
This is just like a normal push but you are making sure you push to the branch instead of the main 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:
- In GitHub – open the forked repository (your copy)
- Click “New Pull Request” on the left-hand side
- Select the original repository on the left and your forked repo on the right
- You should see an alert notifying you that the branches can be merged – this means there is no conflicting code
- 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 main 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! 😊
Latest comments (49)
Hi Laura! I was struggling with Git as a novice. Then an angel on twitter recommended this article. Now I start understanding.
I think this no jargon series is so worthy because it encourages and stop the intimidated learner from falling apart. I cannot thank you enough.
Hey!! That’s exactly what I was hoping to achieve! So glad it was a help to you. I’ll definitely be writing more in the future 😁
Hi Laura. Great article.
A couple of things:
Thanks for the comments!
Will people with Debian based Linux distros know what you mean by that? Or can you explain to me what that means/what its good for?
Cheers :)
Yeah. right after hitting the Submit button I realized what I had done. You wrote a beautiful non-jargonized (is that a word?) article and I went and replied with a bunch of jargon. D'oh!
So anyone who needs to know will understand the jargon that I spouted.
How much do you know about Linux? I don't want to be caught mansplaining.
Haha you just made it a word 🤷🏼♀️😂 no worries. I know nothing of Linux but I’m happy to include a little snippet if it’ll be helpful to Linux users! You can DM it to me if you’d prefer? 😊
Actually the ‘-u’ in git push means ‘—set-upstream’
Thanks I’ll update that now 😁
Amazing blog, I loved it. 😍
Hi Laura, very helpful guide! I come here many times to check ;)
on this part
'8. THE REALLY SCARY ONE Type: git push origin main'
Do you know why 'git push origin main' didn't work but 'git push -u origin master' did for me?
Hey! Thank you! I have to admit I'm not entirely sure, -u generally means update so could it be that you'd already updated once? I notice in the first statement you've used main instead of master was that just a typo?
I'd used it right after 'git remote add origin'.. Oh yeah maybe it is all because of 'main', it should have been 'master'.
Then Laura another typo alert, there's another 'main' in 'YES! I DID IT! BUT WHAT DO I DO NOW?!' section :)
Did you update a page?? I thought I was in different page! looking good!
Haha yes I updated it! Thanks for letting me know I’ll get on to that now! Sorry for any confusion caused 😁
Nah glad I contributed :p
First Article got the git badge! Congrats, thats no easy feat. Well done
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 😁
This article is amazing. Thanks for sharing it!
Cheers Brian!!! :)
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 👀
Thanks for this...was really clear and easy to understand👍
No worries at all! Glad you found it easy 👍😁
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:
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! 😁
Ok thanks
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 😁
Thanks for the detailed feedback that’s really helpful 😁
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 😁
Thank you 😊