When I started using Git, no GUI tool existed to manage a repository. Everything had to be done via the command line. After a few years, some good tools were introduced, and turns more productive the developer lifecycle with some Git GUIs and Git tools integrated into IDEs. In this series of posts, I won't talk about Git GUIs. I will talk about Git in the command line, and we will start right now.
The first thing we need to do before using Git is configure our identity. Our identity contains our name and email. This is important to define the authorship of the commit. To do this globally to your machine, type the following:
You can check what value is set up by removing the last parameter.
This global configuration is stored in the
.gitconfig file in the home directory. You can check all the Git configurations this way:
Also, if you need to specify a different identity to a specific repository in your machine, remove the
--global parameter and execute the command inside your repository.
When you do this, this configuration is stored in the config file inside the
.git directory of the project, and you can see what exists inside it.
With this, we are ready to continue to use Git. But I will show you another configuration. You can choose the editor that you will use when Git asks you for a message commit or do another thing that can’t be done alone by it. You can choose the preferred editor to interact with when Git asks something to you. The
vim editor will be chosen by default on Unix machines if nothing is configured, but you can choose the
nano if you prefer it.
I am used to
vim. I don’t like
nano. But for the first-timers using the command line, it might be better to use some code editor to do this, like VS Code.
You can check how to configure other editors, like Sublime and TextMate, by reading this documentation.
After this, you are prepared to create your first repository.
When we create a new project using an IDE, usually, the Git repository is created automatically. But, if we are not using some robust code editor or simply creating a new project from scratch, we can type the following to create a new folder and a repository inside it:
With this simple command, a folder with the name of your project will be created where you are in the command line, and the repository will be started. You will see a hidden folder called
.git inside your project. On macOS, you can hit the
CMD + SHIFT + . shortcut to see it because it is a hidden folder. But listen: Do not touch this folder, as you may damage your repository.
If you already have a folder or an entire project in a specific directory and want to create a repository, proceed by omitting the project name.
Now we are ready for the next step: Add some files to the repository.
When updating a project and needing to version it, we must add these changes to the repository. The first step is to include the modified files using the following command:
This command will add your entire changes. If you prefer, you can specify the name of a specific file or directory to add. This is useful when you want to split your commits.
You can specify more than one file or directory at a time. Just add a space and the name that you want.
Also, you can add files using Fileglobs to match your files by extension, for example. Suppose you change Swift files and text files and want to add only Swift files in the commit:
I will share more tips on this command, but not now. This command adds the files to the stage but we haven’t committed them yet. Let’s learn this now.
Now is the time to incorporate our changes into the repository’s history.
If you follow this approach, Git will ask for the commit message. I recommend incorporating the commit message through a parameter to avoid any prompts from Git.
The message commit can be divided into two parts: title and description. In the example above, we specify only the message title. Following good practices, we need to be very concise in the title. If we need to add an explanation, we can break the line twice and write a long description with details. Note the quotation mark is not at the end of the title. It is located at the end of the description.
For commit messages best practices, I suggest you read this post. It was written in 2014 but is still very relevant.
Type the status command to see what is happening in your working directory.
Below the command, Git tells me I am on a branch named main, and there is nothing to commit. If I change some file that already exists in the repository, the result is the following:
We can’t see here, but Git shows us in red the unstaged files. If we add the file to the stage using
git add and run again
git status, the file will appear in green color.
If we add some new file to the repository, Git will tell us the file is untracked, and you can track it using
And now, what is next? Let’s see the log of the commits.
Every commit into the repository can be visualized using the log command. You can check who made it, when, and what it does based on the commit message. Also, you can use the commit hash to see the entire change, but we won’t see this in this basic post.
If your repository has a lot of commits, they will be paged based on the height of your terminal. To navigate and see more commits, just press space.
The journey continues
I believe these are the first commands you will need when using Git for the first time, and you will use them frequently. But this is not the end! Stay tuned because I will soon publish more posts about Git, covering additional commands.
Share your thoughts on this post in the comments. Is there another essential Git command you believe should be included?
See you soon!