Git – local workflow and commands you must know

02.10.2024

By: jjuranek

In this article, we’ll delve deeper into a typical Git workflow, from starting a new repository to creating commits. We’ll also explore the essential Git commands that every developer should know. After reading this article, you’ll have a stronger understanding of how to work with Git and be ready to utilize it in your own projects. This article assumes that you have the Git software installed. You can easily verify this by typing the following command into your cmd:

     git --version

You should be good to go if you see any version number and no errors. However, remember to check for the latest versions of your software from time to time. As of now, the latest version of Git is 2.46.1.

If you don’t have Git installed, you can find information on how to do so on the official Git website: https://git-scm.com/book/en/v2/Getting-Started-Installing-Git

Remember about Config

If you’ve never worked with Git, chances are you’re missing some Git config settings. While there are many options you can manage through Git config, the two you should set are your name and email. You can verify if you’ve already set them up by using the following command:

     git config --global --list

If you get some error after using the command, it can be because your global config file doesn’t exist. If, instead, some list is displayed, but you can’t see the user.email or user.name entries, you can easily set them up with:

     

   git config --global user.name “your user name”
   git config --global user.email you@yourmail.com

Note that if your name contains spaces, you should put it into quotation marks. This is important, as when you put your work online later, your commits will have you listed at the author. It’s easy to forget about it if you don’t set it up at the beginning of your work with Git.

git init – How to create your repository

The first thing you should do when starting your new project is to initialize your Git repository. There’s also an option to clone an existing repository, but we’ll discuss that in a different article. To create your repository, you can use the Git init command with a single argument as follows:

     
git init YourRepositoryName

This command will create a new directory with the name you passed as <YourRepositoryName> in your current working directory (the location where your cmd is currently open). The Git init command will also create a .git directory within this newly created folder. The .git directory is where all the information about changes in your project is stored. Feel free to explore its contents, but be cautious—any changes could result in the loss or the destruction of all the information about your project. It’s best not to modify anything there and to interact with Git only through its commands.

Git is a powerful and versatile tool, partly because it offers more than a hundred commands, each with multiple options to modify their behavior. Let’s consider the Git init command, for example. You can provide the -b flag followed by a name to set a default branch name that’s different from the original in your project. Although it’s impossible to cover all these commands in a single article, whenever you encounter a task that isn’t covered by the most common Git commands, check the Git documentation (https://git-scm.com/docs) — there’s a good chance you’ll find exactly what you need!

Creating your first commit

Now that your newly created repository is ready, you can start adding commits. As you probably remember from the previous post, a commit is essentially a version of your project. A commit consists of the changes you made, its ID, a commit message, and some metadata stored by Git.

Remember to enter the following commands inside the folder Git created for you while initializing your repository. Although the repository was created, your working directory hasn’t changed. To do this, you can simply:

     
cd YourRepositoryName

To create a commit, you must first have some changes to save. If you’re working on a real project, those changes would typically involve your source files, etc. But for the sake of this article, we can simulate this change by simply creating some dummy files. Go ahead and enter this in your cmd:

     
echo “console.log(‘Hello world’);” > main.js

Now, let’s use another common Git command; go ahead and type this into your terminal:

     
git status

Git status lets you examine the current status of your repository. It helps you understand what changes will be included in the next commit. When working on a real project, it’ll arguably be the command you use most often. In our example, when you execute that command, you should see a screen similar to the one below:

Example output of git status command. main.js file is not traced

The main message indicates that there are some untracked files. By default, Git won’t track changes in any file until you ask it to do so. You can achieve that by using another Git command:

     
git add "name of the file"

This command will add all the files you listed as arguments into the staging area (more on that later). Instead of hearing people saying, “add this file to the staging area,” you’ll often hear “stage that file”. If you want to stage all your current changes instead of listing them all one by one, you can simply use:

     
git add .

What is that staging area?

We can distinguish three main states that your files can be in while working with Git:

Your working directory: These are the changes you’re currently working on. Any changes you’ve made since the last commit will be here by default.
Staging area: These files are prepared to be included in the next commit. You can think of this area as an open box that you’re preparing to put on a shelf. As long as you’re preparing that box you, can add as many things as you like there.
Committed changes: These are changes that are part of the version of your project. Continuing with the analogy of a box, committing your changes is equivalent to closing that box, labeling it and putting it onto a shelf. After a commit, a new empty box (staging area) is ready for you to start adding changes to it.

Why use a staging area? You don’t always want to include all of your current changes in a commit. It may happen that some of your changes are for local configuration, or you might be working on multiple changes at once and decide that the DB changes should be included in one commit, while the API changes should be included in the next. A staging area allows you to decide what will be committed and what will remain in your working directory.

When you have your changes prepared in your staging area, the last step is to create a commit. Before doing that, , you can use the Git status command to check what has changed. You’ll notice that your file is listed as “changes to be committed.” So, let’s proceed! Use the following command:

     
git commit -m “Initial commit”

And here we are: your first commit is ready!

If you ever add something to the staging area by accident or later decide that you don’t want to include it in the next commit, you can unstage that file by using this command:

     
git restore --staged nameOfFile

Ignore them

If you’re working on a project that uses a lot of external code (like Node modules), or storing a config file unique to each developer, you shouldn’t track these with Git. However, it can be cumbersome to remember to exclude certain files or directories in every commit. Thankfully, there’s an automated way to ignore them in Git. In the root directory of your repository (where the .git file is located), you can create a .gitignore file. This gitignore file is basically a list of all the paths to directories and files in your repository that you don’t want to be tracked by Git. If you’re not sure what you should include in your .gitignore file, you can check out this GitHub repository: https://github.com/github/gitignore , which contains a list of gitignore files for many popular languages and frameworks for inspiration.

Exploring history of your commits

Another useful command is the one that comes in handy when you want to examine the history of your commits:

     
git log

Git log is a versatile command with multiple options. You can format and customize the output of this command however you like. For example, one of my favorites is to use the --graph flag, which shows the connections between your commits in a more user-friendly way. You can experiment with other options to create output that best suits your needs!

Introducing branches

Up until this point, we were using only a single branch called “main”. In real projects, you shouldn’t commit anything directly to your default branch. It often represents the latest stable version of your project, which every other developer should use as the basis for their work.

Instead, you should create your own branch and commit changes there. After your work is done and tested; you can combine your branch with the main. This article is already packed with information, so the topic of branches will be explained in the next one.