Git and GitHub basics: a beginner's guide

Anyone who starts learning to programme soon hears two words: Git and GitHub. “Ability to work with Git” also appears in almost every developer job advert. In this guide we look at why version control matters, how Git differs from GitHub, how to install and set up Git, its core concepts, how to create your first repository step by step, how to send it to GitHub and get it back, and what branches, Pull Requests and conflicts are. We then cover using GitHub as a portfolio, security rules and common mistakes. At the end you will find a practice exercise and a checklist. Every command is real, so you can try them in your own terminal.

Why version control matters

Do you have files on your computer called “coursework_final”, “coursework_final_v2” and “coursework_final_v2_really_last”? It is a very common problem: nobody knows which copy is really the latest, what changed between them, or where the paragraph deleted yesterday went. In our article on organising your files we looked at simple fixes. For code and text projects there is a more powerful tool: a version control system.

A version control system remembers every saved state of your project: who changed what, when and why. At any moment you can go back to an earlier state, compare two versions, or have several people work on one project without breaking each other’s work.

How Git differs from GitHub

The two names are often mixed up, but they are different things:

• Git is a free program you install on your computer. It works without the internet and keeps the project history locally, on your machine.
• GitHub is a web service for storing Git repositories online and working on them together. You can browse and discuss code there, collaborate as a team and even host a simple website.

A simple comparison: Git is the camera, and GitHub is the online album where the photos are kept and shared with friends. Without the camera the album is empty; without the album the photos stay on one device. GitHub is not the only service of this kind (there are also GitLab and Bitbucket), but it is the most popular among beginners.

Installation and first-time setup

Download Git from the official site, git-scm.com.

• Windows. Run the installer; the default settings are fine for a beginner. Afterwards Git Bash appears in the Start menu. Type the commands from this article there.
• macOS. Type git --version in Terminal. If Git is missing, the system will offer to install the tools it needs.
• Linux (Ubuntu). Use sudo apt install git.

Check the installation and introduce yourself. Your name and email are recorded in every commit, so set them up correctly once:

git --version
git config --global user.name "Bekzod Karimov"
git config --global user.email "bekzod@example.com"
git config --global init.defaultBranch main

A note on the last line. The main branch used to be called master by default. Today GitHub and most projects use the name main. With this setting your new repositories start with main straight away. If you see master in older tutorials, it is the same thing under its old name.

Core concepts in plain language

Understand four concepts and the rest of Git becomes much easier.

• Repository (repo for short): the project folder together with its whole history. From the outside it looks like an ordinary folder, but inside there is a hidden .git folder where the history lives. Do not delete it by hand.
• Commit: a “snapshot” of the project at a particular moment, with a short note attached. It is like a save point in a game: if you make a mistake, you go back to it.
• Branch: a parallel line of work. The main line (main) stays untouched while you try out a new idea on a separate branch. If you like the result, you add it to the main line; if not, you throw it away.
• Remote: a copy on the internet, for example a repository on GitHub. It is usually called origin.

One more important idea is the staging area. Git does not automatically save everything that has changed. First you use git add to choose which changes go into the next commit, then git commit takes the snapshot. It is like choosing what to put in a bag and then zipping it shut.

Your first repository, step by step

Bekzod is a university student writing his coursework in a Markdown text file. He wants to save its state after finishing each chapter. Let us follow his path.

Step 1. Create a folder and initialise the repository.

mkdir kurs-ishi
cd kurs-ishi
git init

git init creates an empty repository inside the folder. You run it only once per project.

Step 2. Check the status. Bekzod creates a file called hisobot.md in the folder and writes the introduction. Then:

git status

git status is the command you will use most. It shows which files are new, which have changed and which are ready to be committed. Whenever you are unsure what to do next, type this first.

Step 3. Stage the change and commit.

git add hisobot.md
git commit -m "Kirish qismini yozish"

To add all changed files at once, use git add . (the full stop means the current folder). Before that, though, check with git status exactly what is being added.

Step 4. View the history.

git log --oneline

Each commit appears on one line: a short code (identifier) and its message. To see what has changed since the last commit, type git diff.

Writing a good commit message

A commit message is a letter to your future self or to a colleague. “changes”, “fixed” or “asdf” say nothing. A good message:

• is short, roughly up to 50 characters;
• says what was done: “Add reference list to chapter 2”;
• describes one logical change; if you did two different things, make two commits;
• is written in one language and one style across the team.

The .gitignore file

Some files should never go into a repository: temporary files, system files, library folders and, most importantly, passwords and secret keys. You list them in a .gitignore file in the project root:

# sample .gitignore file
.env
node_modules/
*.log
.DS_Store
Thumbs.db

Note: .gitignore only affects files that Git is not yet tracking. If a file has already been committed, you need to stop tracking it with git rm --cached file_name and then commit.

Working with GitHub: push, clone, pull

Creating an account and a repository

1. Register on github.com via Sign up. Choose your username carefully, as it will eventually become your portfolio address.
2. Click the + in the top right corner and choose New repository.
3. Enter a name (for example, kurs-ishi) and choose Public or Private. If you plan to upload a repository from your computer, do not tick “Add a README file”; the repository should be empty.
4. Click Create repository. GitHub will show you the repository address.

Connecting your computer to GitHub and pushing

git remote add origin https://github.com/bekzod-karimov/kurs-ishi.git
git push -u origin main

git remote add registers the online copy under the name origin. git push sends your commits to GitHub, and -u remembers the link, so next time a plain git push is enough. If your branch is still called master, rename it first with git branch -M main.

About signing in: GitHub does not accept your account password in the terminal. On Windows, Git Credential Manager, which comes with Git, opens a browser window on your first push, and you sign in there. On other systems you use a personal access token created in your GitHub settings, or an SSH key, instead of a password.

Working on another computer: clone and pull

Bekzod wants to work in the university computer room. He downloads the repository with its full history:

git clone https://github.com/bekzod-karimov/kurs-ishi.git

When he finishes, he runs git add, git commit and git push. Back home, he fetches the new changes onto his home computer:

git pull

The golden rule: git pull before you start work, git push when you finish.

Branches, Pull Requests and conflicts

Nilufar and Javlon are building a small website together for a college project. Nilufar is writing the “About us” page and Javlon the contact form. If both work directly on main, they may break each other’s work. So each of them opens their own branch.

Working with branches

git switch -c biz-haqimizda
# edit the files, then:
git add .
git commit -m "Biz haqimizda sahifasini qo'shish"
git switch main
git merge biz-haqimizda

git switch -c creates a new branch and switches to it. git switch main takes you back to the main branch, and git merge brings the branch’s changes into the current one. git branch lists all branches. Older tutorials use git checkout -b, which still works, but git switch is clearer.

The idea of a Pull Request

In a team, branches are usually merged on GitHub rather than on someone’s computer. Nilufar pushes her branch with git push -u origin biz-haqimizda and clicks Compare & pull request on GitHub. A Pull Request (PR) is a request that says: “please review my changes and add them to the main branch”. Javlon reviews the changes line by line, leaves comments and asks for fixes if needed. If everything is fine, someone clicks Merge pull request. That way only reviewed code reaches main.

Conflicts and how to resolve them

If both of them change the same line of the same file in different ways, Git cannot decide on its own which version is right. This is called a conflict. It is not an error, just a normal situation. Say both changed the heading in index.html. When merging, Git adds markers to the file:

<<<<<<< HEAD
<h1>Kollej loyihasi</h1>
=======
<h1>Bizning jamoa sayti</h1>
>>>>>>> biz-haqimizda

From HEAD to ======= is the version on the current branch; below it is the version from the branch being merged. To resolve it:

1. Open the file in an editor and keep the correct version (or combine both).
2. Delete the <<<<<<<, ======= and >>>>>>> lines.
3. Save, then run git add index.html and git commit.

To reduce conflicts, run git pull often, keep branches short-lived and agree on who is working on which file.

GitHub as a portfolio, and security

README and GitHub Pages

Employers often open the GitHub link on a CV. Add a README.md file to every project: what the project does, how to run it and which technologies it uses. If you create a repository with the same name as your username and put a README in it, it appears on your profile page, acting as a short introduction to you.

Madina has learnt the basics of HTML and CSS, built a one-page site about herself and wants to put it online. GitHub Pages is a free service for exactly that:

1. She puts the index.html file in the root of the repository and runs git push.
2. On GitHub she opens the repository’s Settings → Pages section.
3. Under Build and deployment → Source she chooses “Deploy from a branch”, under Branch she picks main and / (root), then clicks Save.
4. A few minutes later the site opens at username.github.io/repository-name.

She can add this link to her CV and LinkedIn profile. For more tips, see our article on building a portfolio.

Security rules

• Never upload passwords, tokens or secret keys to a repository. Keep them in a separate file such as .env and add it to .gitignore.
• If you have uploaded one, change the key immediately. Deleting the file in the next commit is not enough: it stays in the history, and there are bots that automatically scan public repositories.
• Turn on two-factor authentication: Settings → Password and authentication. GitHub itself increasingly requires it from users who upload code.
• Be careful with personal data: copies of passports, lists of phone numbers and other people’s details have no place in a public repository.

General rules are covered in our article on staying safe online.

Graphical tools

You do not have to use the terminal. GitHub Desktop is a free app for Windows and macOS: commits, push, pull and branches are all done with buttons. In the VS Code editor, the Source Control section in the left panel shows your changes and lets you commit them. Still, it is worth learning the core commands in the terminal once: graphical apps run exactly these commands, and when something goes wrong you will understand what is happening.

Common mistakes

• Putting everything in one commit. A week of work in a single commit called “everything” makes the history useless. Commit after each logical step.
• Uploading a secret file. Accidentally adding .env or a file with passwords via git add .. Always check git status before committing.
• Switching computers without pushing. Bekzod worked at the university and forgot to push, so the old version is waiting for him at home. Finished? git push. Starting? git pull.
• Deleting the .git folder or nesting repositories inside each other. The whole history is lost or tangled.
• Panicking at a conflict and cloning the folder again. Reading the conflict markers and resolving them by hand is usually a minute’s work.
• Unclear commit messages. “fix”, “new”, “123”: in a month even you will not understand them.

Practice exercise and checklist

Consolidate what you have learnt in an hour of practice:

1. Install Git and set your name and email with git config.
2. Create a folder called mashq and run git init.
3. Write 3–4 lines about yourself in a README.md file and make your first commit.
4. Create a .gitignore and add .env to it. Create a .env file and check that it does not appear in the git status output.
5. Change the file twice more and make commits with clear messages; view the history with git log --oneline.
6. Create an empty repository on GitHub and upload your project with git remote add and git push -u origin main.
7. Open a branch with git switch -c tajriba, make a change, commit it, go back to main and run git merge.
8. Edit the README on GitHub in the browser, then run git pull on your computer.
9. If you like, add a simple index.html and turn on GitHub Pages.

Checklist

• Git is installed, name and email are set, the main branch is main.
• Commits are small and their messages are clear.
• There is a .gitignore, and no secret files are in the repository.
• Two-factor authentication is on for your GitHub account.
• git pull at the start and git push at the end have become a habit.
• Every public project has a clear README.

Git is a programmer’s everyday tool, but it is also useful for text documents, coursework and website projects. If you are only just thinking about how to start programming, get into the habit of using Git from day one.

If you would like to learn programming systematically with a teacher, take a look at our association’s free programming programme and other training programmes. When you are ready, submit an application and our specialists will get in touch.