Alex de Pablos
Software engineering

Introduction to GIT: Complete Guide from Scratch to Your First Commit

Alex de Pablos Lopez13 min

In the world of software development, speed and efficiency aren’t just about how much code you can write in an hour. Instead, it’s about how you manage, organize, and track that code. This is where our “introduction to GIT” begins, a tool that plays a pivotal role in code management.

If you prefer a visual approach, I’ve prepared a comprehensive video that covers all the points discussed in this introduction to GIT. Throughout the reading, you’ll find references indicating when it’s a good time to complement with the video. At the end of the article, you’ll find a direct link to the visual resource, allowing you to delve deeper into the topics at your own pace. This way, you have the freedom to choose how and when to access the visual content, ensuring a learning experience tailored to your preferences.

GIT, what is it?

Imagine you’re writing a novel. With each chapter you finish, you make a copy and store it in a safe place. If later on, you decide you don’t like a chapter, you can go back to a previous version without losing all your progress. GIT does something similar, but for code. It’s a version control system that allows you to track changes in your code, revert to previous versions, and collaborate with others without stepping on each other’s toes.

Why is it essential for developers?

Now, you might think, “Well, can’t I just save different versions of my code and that’s it?” Technically yes, but that would quickly become chaotic. Imagine working with a team where each member has their own “version” of the project. Or trying to remember what changes you made two weeks ago and why. GIT, like a good detective, keeps a record of all changes, who made them, and why. Everything is logged there and is designed to make our lives easier. Especially for those of us who, like me, don’t have a good memory.

The Art of Version Control

Version control is an absolute necessity in modern development. It’s about having a history, being able to collaborate, and protecting your code from potential errors. And GIT, in this scenario, is like a superhero of version control. It facilitates this process, making it intuitive and efficient, and allows developers to focus on what they do best: develop.

Installation and Configuration: Preparing Your Machine for GIT’s Magic

Great! If you’re here, it’s because you’re convinced that GIT is an indispensable tool in your developer arsenal. Let’s see how to install and configure GIT properly. Join me in this process!

Step by Step to Install GIT

  1. Windows
    • Go to gitforwindows.org.
    • Click on “Download” to get the latest version of GIT for Windows.
    • Run the downloaded file and follow the installation wizard’s instructions.
  2. MacOS
    • If you’re a macOS user, you’re in luck because GIT is likely already pre-installed. You can check by opening the Terminal and typing git --version.
    • If it’s not installed, you can get it through the Homebrew package manager with the command brew install git.
  3. Linux
    • Open your terminal.
    • Depending on your distribution, use one of the following commands:
      • Debian/Ubuntu: sudo apt-get install git
      • Fedora: sudo yum install git
      • Arch Linux: sudo pacman -S git

Setting Up Your Identity in GIT

Now that GIT is installed, it’s time to introduce yourself. It’s vital for GIT to know who you are to track who does what when in a project.

  1. Open your terminal or Git Bash (on Windows).
  2. Type git config --global user.name "Your Name" to set your name.
  3. Enter git config --global user.email "youremail@example.com" to set your email.

With those two commands, you’ve told GIT who you are. It’s that simple.

Watch this section in the video ↗

Your First Repository: First Steps in the World of GIT

Within the vast universe of version control, it’s easy to get confused with so many terms and tools floating around. So, before diving into creating and cloning repositories, let’s pause and understand some key concepts.

GIT vs. GitHub/GitLab:
It’s common to confuse GIT with platforms like GitHub or GitLab. Let’s understand it this way:

  • GIT: It’s the tool itself, the version control system that records every change, allows collaborations, and many other wonders we’ll discover.
  • GitHub/GitLab: They are online platforms that use GIT to host projects. Think of them as public or private libraries where you can store, share, and collaborate on projects with other developers worldwide.

Now that we’ve made that distinction, let’s see how to work with GIT on your machine.

Creating Your Own Repository with git init:

  1. Choose your workspace: Before starting a new repository, decide where you want it to live on your computer. It could be a new project or an existing one you want to add version control to.
  2. Initialize your repository: Open your terminal or Git Bash and navigate to the chosen directory using the command cd path/to/directory. Once there, type git init. Just like that, you’ve created a new GIT repository. In the background, there’s a hidden folder called .git that stores all the magic.

Cloning an Existing Repository with git clone:

Suppose you come across an interesting project on a platform like GitHub or GitLab and want a local copy to play with or collaborate on.

  1. Find the repository: This is usually a link provided by someone else or found on such platforms. It will look something like this: https://github.com/user/repository-name.git.
  2. Clone the repository: Go back to your terminal or Git Bash. Decide where you want the repository to download on your computer and navigate to that location. Then, type git clone repository-link. GIT will download the entire repository to your chosen directory.

Watch this section in the video ↗

Making Changes: Add, Commit, and Status

One of the most crucial aspects of working with GIT is the process of making changes to your code and how those changes are tracked and recorded. Imagine you’re writing a diary; each time you add an entry, you’re making a change. But you wouldn’t want every fleeting thought to be permanently recorded, right? You’d want to review it, make sure it truly reflects your thoughts, and then, when you’re satisfied, save that entry. That’s the essence of the basic work cycle in GIT.

The Basic Work Cycle:

Making Changes, Preparing Changes, and Confirming Changes are the three pillars that will guide you throughout your GIT experience.

Working Area, Staging Area, and Commits

As you get familiar with GIT, it’s essential to understand its architecture and how changes are handled at different stages. Imagine GIT as a writer organizing their thoughts before publishing.

  • Working Area (Working Directory):
    It’s the writer’s desk where they draft, make annotations, and change paragraphs. Technically, it’s where you make changes to your files and reflects the current state of those files on your system.
  • Staging Area (Index):
    When the writer is satisfied with an idea, they place it in a special spot, ready to be included in the final book. In GIT, this is the Staging Area. Using git add <file>, you move changes from that file to this area, preparing them for their final confirmation.
  • History (Commit History):
    When the writer decides that a part of their work is ready to be published, they add it to the book. In GIT, this “book” is the commit history. By running git commit, you create a new record of those changes in the history.

Using git status to check the current state

Before doing anything, it’s good to know where you stand. The git status command shows you which files have been modified, which are prepared for confirmation, and which are not. Think of it as your compass in this world of changes.

Using git add to add changes

You’re ready to prepare your changes. Use git add file-name for a specific file or git add . for all modified files. It’s the process of selecting which items you’re ready to confirm.

Using git commit to confirm changes

After reviewing and preparing your changes, it’s time to confirm them. With git commit -m "Descriptive change message", you leave a brief note about what you did. This way, you can review your history in the future and know exactly why you made those changes.

Watch this section in the video ↗

Connecting with the Outside World: Pull and Push

GIT is not just a tool for tracking changes locally; it’s also a gateway to collaborate and share with others in the vast world of development. Just as you might want to share your thoughts with friends through letters or emails, in the GIT universe, that communication is done through operations like ‘pull’ and ‘push’. These commands allow you to interact with repositories stored in the cloud, where entire teams can collaborate on a project.

Introduction to Remote Repositories

A remote repository is like an online library. While your computer hosts a local copy of your projects (your personal little library), the remote repository is a cloud version accessible to you and possibly other collaborators. It’s where everyone can get the most recent versions of the code and share their updates.

Getting updates with git pull

Think of git pull as checking your mailbox. Are you expecting a letter from a friend or a package? When pulling, you’re picking up the latest updates that others have shared in the remote repository and bringing them to your local copy. It’s a way to stay up-to-date with the most recent changes others have made.

Sending your changes with git push

On the other hand, git push is like sending a letter. You’ve written something new, made some changes, and now you want to share them with the world. By pushing, you’re sending your updates to the remote repository so others can see and work with them. It’s your contribution to the collective project.

Watch this section in the video ↗

History and Navigation: Log and Checkout

GIT is like a time capsule for your project, allowing you to explore its history, relive previous versions, and correct past decisions. Let’s dive into the commands that make this time journey possible.

Exploring History with git log

The git log command acts like a detailed diary of your project. Every time you confirm a change, you’re leaving a mark in this log. Using git log is like reviewing an old photo album, where each photo (or commit) has a date, a description, and the name of the person who took it.

  • Basic Command: By simply running git log, you’ll get a list of all the commits in reverse chronological order. Each entry shows the commit identifier (a long alphanumeric code), the author, the date, and the commit message.
  • Custom Views: With different options and parameters, you can customize the view. For example, git log --oneline displays each commit on a single line, offering a more compact view.

Switching between different states with git switch

The git checkout command used to be the default tool for switching between branches or revisiting previous commits. However, due to its multifunctionality, it could be confusing. GIT introduced git switch to simplify the task of switching branches.

  • Switching Branches: To move between branches, simply use git switch [branch_name]. It’s a direct and clear way to change the development line.
  • Creating a New Branch and Switching to It: If you want to create a new branch and switch to it immediately, you can use git switch -c [new_branch_name].

Undoing Changes with git revert

Sometimes, we all wish we could turn back time, especially when we make a mistake. In GIT, git revert is the command that allows you to do just that.

  • Reverting a Commit: To undo the changes introduced by a specific commit and create a new commit that represents that reversal, simply use git revert [commit_identifier].

Going Back in Time with git checkout

GIT offers you the incredible ability to time-travel in your code. Imagine that each change you make is like writing a new chapter in a book. And sometimes, you’d wish you could go back to a previous chapter to remember or review something. git checkout and git switch are the tools that allow you to do just that.

Although git switch is the modern recommended tool for jumping between branches, git checkout has special power: it allows you to look at any previous “chapter” without committing to changing it. When you do this, you’re in a state called “detached HEAD”, which is basically a way of saying you’re in read-only mode. It’s like opening an old book and flipping through it without intending to write in it.

Returning to a Previous Commit: If at any time you need to revisit a previous state of your project, you can use git checkout [commit_identifier]. But remember: you’re in a temporary view mode, so avoid making changes unless you’re sure of your actions.

Navigating between Branches: In project development, different branches are often created to work on specific features or tests. Think of them as alternative paths in a story. git checkout [branch_name] (or the more modern git switch [branch_name]) allows you to jump between these different development paths.

Watch this section in the video ↗

If you wish to delve deeper into Git commands and learn some handy tricks, I recommend reading my article on the most common Git commands.

Video

For those who prefer a visual approach, I’ve prepared a comprehensive video that covers all the points discussed in this article. This video will guide you step-by-step through the world of GIT, covering the following topics:

Conclusion

We’ve embarked on a fascinating journey through the world of GIT, an introduction to a universe where every change, every line of code, becomes part of a constantly evolving chronicle. From starting a project with git init, tracking our changes with git add and git commit, to sharing our work with the outside world through git push and git pull, we’ve laid the groundwork to become expert narrators of our own code story.

Throughout this introduction to GIT, we’ve learned how to review our history with git log, go back in time with git checkout, and even venture down different development paths using branches. But, like in any good story, this is just the beginning.

If you feel that your curiosity has been piqued and you’re ready to dive deeper into the ocean of GIT, good news! I will soon be releasing a more advanced article for those who want to take their skills to the next level. Prepare to discover secrets, tricks, and techniques that will turn you into a version control master.

Until then, keep experimenting, practicing, and above all, keep coding!

Remember, learning is a journey, not a destination. So keep exploring, keep asking, keep learning. And while you do, don’t forget to enjoy the journey. See you in the next post, where we will continue to unravel the mysteries of Software Engineering together. Until next time!