An introduction to Git for beginners

What is Git? Are Git and GitHub the same? How do you get started with Git? What are the basic Git commands a developer should know?

If you’re looking for answers to these questions, Kedasha Kerr has your back. A developer advocate at GitHub, Kedasha breaks down the basics of Git in the video below and in her blog post that covers Git for beginners. 

To build your familiarity with Git, we’ll use this issue of Branching Out_ to recap the fundamentals covered by Kedasha and compile resources that are readily accessible to you. You’ll learn how to install and configure GIt as well as the most common Git commands to run while using the most widely used version control system (VCS) in the world. 

1️⃣ Let’s start by answering this popular question: Are Git and GitHub the same? 🤔

No, they’re not. 

Git is a VCS that tracks file changes. GitHub is a platform where developers can collaborate and store their Git repository in the cloud. The repository acts like a central hub for a project’s files, documentation, and version history. ( 📝Friendly reminder that this difference only scratches the surface. Developers can do much more on GitHub, which we’ll cover below.) 

To understand how a VCS like Git works, it might help to understand how it doesn’t work. 

As an example, let’s look at how you save your resume files.

On your computer, you might have separate files labeled resume, resumev2, resumev4, etc. With version control, you wouldn’t need separate files for each change to your resume. You could keep one resume file because Git, the VCS, would track all the changes for you. So, you could have one file where you’d be able to see the latest version of your resume by default but choose to see, in that same file, your resume’s history, previous versions, and all the changes you’ve made over time.

Why, as a software developer, should you use Git as a VCS to track file changes? 

 With Git, you can: 

• 💾 Save, back up, and restore previously written code.
• 🤖 Work with multiple developers on a single project without overwriting each other’s changes. Each developer working on a main project can write new features or experiment with the source code without affecting the main codebase. 
• 🌐 Have a full copy of the project and project history when you’re working, not just a copy of the file you’re working on. Git is a distributed VCS, or DVCS, which allows you to work offline and without a constant connection to a central repository. You only have to connect to the central repository to push your changes or pull updates from others.
• 🖥️ Merge proposed code changes from multiple developers into a single source. The changes you and other developers make in your own copies of the code can be merged into the main codebase.
• 🧠 Identify and resolve conflicting code changes proposed to the main codebase.
• 📱Track all code changes in addition to who made the changes, when, and why.
• 👨🏻💻 Review a timeline of code changes and decisions, which can clarify how a codebase has evolved to its current state and why certain changes were made. 

You can see why Git is valuable for developers who want to virtually collaborate on a project. Its benefits apply to open source communities and enterprise teams alike.

🌟 Fun fact: Git was released in 2005 and still a new open source VCS when GitHub was founded in 2008. In fact, only 2.4% of companies adopted Git according to a 2009 Eclipse community survey. As of 2023, 93% of developers are using Git, according to Stack Overflow. 

⏪ Want to take a walk down memory lane? Check out this old Stack Exchange thread about Git and Subversion or this history of Git. 

Here are seven Git terms to know:

• Working directory: this is where you make changes to your files. It’s like your workspace, holding the current state of your project that Git hasn’t yet been told to track.
• Staging area: also called the index, this is where you prepare changes before committing them. It’s like a draft space, allowing you to review and adjust changes before they become part of the project’s history.
• Branches: branches are parallel versions of your project. They allow you to work on different features or fixes independently without affecting the main project until you’re ready to merge them back.
• Local repository: your local repository is your project’s history stored on your computer. It includes all the commits and branches and acts as a personal record of your project’s changes.
• Remote repository: a remote repository is a version of your project hosted on the internet or network. It allows multiple people to collaborate by pushing to and pulling from this shared resource.
• Pull request: a pull request is a way to propose changes from one branch to another. It’s a request to review, discuss, and possibly merge the changes into the target branch, and is often used in team collaborations.
• Merge: merging is the process of integrating changes from one branch into another. It combines the histories of both branches, creating a single, unified history. 

So, what does GitHub have to do with Git?

You can use GitHub to host your Git repositories. But if that’s all you use it for, you’re missing out on everything else the platform has to offer. 

That’s not to say cloud storage isn’t a big deal. It is. By hosting your code on GitHub, you won’t lose your work if something happens to your local machine. All we’re saying is you can do more than that on a platform built specifically for developers.  

In addition to storing your code, here’s everything else you can do on GitHub:

• Share your work and collaborate with other developers from all over the world. Use this checklist and guide to get your repository collaboration-ready. You can also engage with developers using GitHub Discussions, a place to ask open-ended questions and share your ideas for a project.
• Integrate GitHub tools and services directly into your workflow. For example, with GitHub Actions you can set up automated workflows to verify and test your code whenever you push changes to the main repository. This gives you faster feedback about code changes and helps you to catch and fix issues earlier in the development pipeline.
• Use AI-powered coding tools to improve productivity. With GitHub Copilot, you can prompt the AI coding assistant to gather and synthesize information relevant to your task, and for assistance in writing boilerplate or tedious code.
• Integrate third-party tools and services directly into your workflow. Take JFrog, for example. You can use CI/CD with GitHub Actions and JFrog Artifactory to gain full visibility over security findings across your software supply chain and simplify governance between source code and binaries.
• Learn and work in the open with pull requests. Pull requests allow developers to review and discuss proposed changes before they’re merged into the main branch. They can improve code quality, facilitate collaboration and communication, create transparency, and capture context around changes made to the codebase. In addition to their practical function, pull requests generate and record rich learning material for development teams.
• Support GitHub’s global developer community. With GitHub Sponsors, you can financially support the hard-working maintainers of open source projects that you find valuable.

In other words, GitHub is more than just a GUI for Git. 

🧠 To learn more about how Git and GitHub work together, read and complete:

📚 Basics of Git

📚 About GitHub and Git

📚 Git cheat sheet

💻 GitHub Skills course 

🎉 GitHub Foundations Certificate

2️⃣ How do you get started with Git? Now that you know the purpose and value of Git for developers, here’s how you can start using it today. 

(🎥 For a visual walk-through of the steps below, skip to this section in Kedasha’s video.)

First, you need to install Git on your machine. 

To install Git on MacOS, here are the four steps you need to follow:

• Get instructions: go to git-scm.com/downloads then click macOS.
• Install Homebrew, which will allow you to easily install software on your machine.  Open up your terminal. Copy the command /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" and paste it into the terminal. Hit enter to run the command. This will take a while to run so give it a few moments.
• Once Homebrew is installed, return to the download page. Open up your terminal and paste the command brew install git and run it. This will run the installer so you can have Git on your system. When it runs successfully, you now have Git on your machine!
• Open up your terminal and run the command git and you should see a list of all the commands available.

✏️ Note: While macOS comes with a preinstalled version of Git, you’ll still want to download it to ensure you have the most up-to-date version.

To install Git on Windows 11, here are the steps you need to follow:

-If you’re using a Windows machine, click on the Windows icon on the download page. This will give you the most recent version of Git.

-Once you have that file on your machine, double-click it and follow the onscreen wizard prompts:

-Click the “Next” button for the following: accept the terms, the location to save Git, and the default selections.

-Reset the default branch name to “main” as that’s the new convention.

-Click the “Next” button to accept the recommended path, the bundled OpenSSH program, and for all the other options.

-Click the “Install” button.

-Once Git is installed on the machine, click the “Finish” button and open your terminal.

-Run the command git and you should see a list of all the commands available.

To configure Git on your machine, follow these four steps:

• Open your terminal and type git config --global user.name "FIRST_NAME LAST_NAME" git config --global user.email "MY_NAME@example.com" at the prompt. Replace the values of FIRST_NAME, LAST_NAME and MY_NAME@example.com and then run the command. This tells Git who is making future changes.
• You can see all the other configuration options that are available by running git config in your terminal. (You don’t need to worry about those options when you’re first configuring Git.)
• For now, you can check who Git thinks you are by running git config –list To see the configuration options you just set.
• Hit Q on your keyboard to exit the screen.

You’re all set up! 👩🏾💻

❓If you have questions or feedback, pop it in the GitHub Community thread, and we’ll be sure to respond!

3️⃣ What are some good-to-know Git commands? Now that you have Git configured on your machine, you’re ready to start running commands. 

We have a top 12 list of Git commands every developer must know and a list of basic Git commands. We’ll share a few below. 

• Git config

Congratulations, you already ran this one when you set up Git on your machine!

• Git init 

This command initializes a new Git repository. 

Before you run this command, you need to create a folder, or directory. Create a new folder with the command mkdir git-practice and then run cd git-practice to go into the folder you just created. Open the folder in your code editor.

From here, you can run the git init command to initiate a new Git repository so that Git tracks all changes made in this directory.

• Git status

Run this command to see all tracked changes to your directory. 

You can see what files have been added, deleted, or modified. If you run this command in a directory with no files, it should return “nothing to commit.”

For more practice, create a new file in your sample folder by running touch hello.md and then run git status again. Now, you should see that you have an untracked file, hello.md.

An untracked file is one that hasn’t been added to the staging area. To add files to the staging area, you can use the git add command. 👇

• Git add 

There are a few ways to use this command. For example, you can use git add . to add all files to the staging area from the working directory or use git add filename to add a specific file to the staging area.

Try creating a new file called learning.py and another file called waiting.py. 

Now, run git status so you can see your changes. Then, run git add learning.py to add this file to the staging area. 

If you run git status again, you’ll see that learning.py is in the staging area and waiting.py is untracked and in the working directory.

If you make additional changes to the tracked files in your directory, you’ll need to run git add again for Git to record those changes. 

To practice tracking new changes, add the code print (“I'm learning git") to learning.py. 

Then, run git status in the terminal. You’ll see that the learning.py file has been modified and has untracked changes. 

Run git add learning.py to keep track of these newer changes.

• Git commit To “commit” a change is to store a version of your project in the Git history.

Currently, learning.py and hello.md are tracked, while waiting.py is untracked.

Run git commit -m "initial commit" and then run git status afterward.

You’ll see that you have “2 files changed, 1 insertion in git” because you just added two new files and one of the files has one line of code. You’lll also see that you have an untracked file—waiting.py—because that file was never added to the staging area.

If you add new changes to the learning.py file, you can add both files to the staging area along with any other changes you make by running a git add. git commit -m "add waiting file and new function" command.

Bookmark the GitHub for Beginners page on the GitHub blog to stay updated on our latest posts and keep it moving on your Git journey! 💪

If you want even more hands-on learning and to interact with the GitHub community in person, “git” your boss to send you to Universe this fall. 😉 Not sure how? We have you covered. Check out our cheat sheet now! 

More GitHub goodness: 

🔥 Subscribe to our developer newsletter.

🧠 RSVP for an upcoming event.

❤️ Repost this newsletter to your network.

✨ This newsletter was written by Nicole Choi and produced by Gwen Davis. ✨