Conversations about Git - Thoughts on Git for Beginners

Issue

Git is a very popular version control and collaboration tool nowadays. However, not everyone knows how to use Git proficiently, let alone its many advanced features. I say this because I have heard many stories about how my colleagues use Git, and at first glance, it seems like they have no problems, but deep down there are many commands that confuse them. I myself have experienced this, and there have been many situations that made me feel confused.

Besides the features that Git offers through command lines, it can be said that most of us do not use Git correctly in terms of mindset. Many people working with Git simply remember a few commands that they frequently use or commands that have been applied in previous projects. This leads to using commands without paying attention to why they need to use those commands.

Starting with personal projects while still in school, I can't really call them projects, they were more like open source projects that I played around with, modifying them according to my preferences. Every time I released a stable version (which could be called "going into production," although I didn't know these terms back then) or prepared to do something big that could change the logic, my approach was to copy the project and make changes on the copy. If the feature was successful, I would keep it, otherwise, I would discard it and start over.

In this way, I would compress each stable version and give it a name along with the compression date. Over time, the number of files increased to a certain extent, and I didn't know what changes each file contained, I could only guess. Or later, I learned to write down the changes in a README.md file.

That was how I developed projects before knowing Git. It can be seen that there are many limitations in this approach, such as constantly copying and not being able to look back at previous changes. I suddenly wondered if all programmers did it this way!

Git appeared! I remember my first encounter with Git, I still didn't really understand the concept of it. If I followed the instructions from Github, I could push my project to the repository on it. It was amazing, now I could share it with others without having to compress and manually send it. Then I learned how to continue pushing new code and reviewing previous changes.

When I started working, I learned more about how to use Git and how to use Git for collaboration. I learned more about Gitflow and the mindset of how Git works, as well as the discussions with colleagues about Git.

Instead of mechanically memorizing how to use it, take the time to imagine the problems that Git can solve. That's why today's article is my sharing about how to use Git for beginners.

Git helps with version control

As in the story at the beginning of the article, without Git, I would have to do many manual, complex, and time-consuming steps. With Git, I can easily "commit" the code I write at each moment, and then develop features and continue committing.

Applying Git to a project is also very simple, just one init command.

$ git init

Commit can be understood as the action of creating a commitment for a code version at the current time. It's like making a copy of the code in another directory and compressing it, but instead of doing it manually, with just one commit command, Git does everything for us.

$ git commit -m "commit message"

After committing, Git keeps a log of the created commits. To view all commits, just use git log.

$ git log

commit 98cd1bfde6dbe39f883324dad476f30dd836b3c4
Author: hoaitx <[email protected]>
Date:   Mon Feb 26 23:50:23 2024 +0700

    fix: some interface bugs

commit 7c24960175c652dabdf1f4615622b0375e81eea8
Author: hoaitx <[email protected]>
Date:   Sun Feb 25 16:37:25 2024 +0700

    feat: adjust interface

If you want to review the code at a specific commit, just checkout to that commit, and all the code will go back to the state of that commit.

$ git checkout 98cd1bfde6dbe39f883324dad476f30dd836b3c4

The 98cd... is the commit hash in the commit history.

But before committing, Git needs to know what changes you made to which files. Usually, we should only create a commit for a specific feature that we have just finished, so ideally, the commit should apply to all the files that have been changed.

$ git add .  

Git helps with centralized code management

When the project only exists on your local machine, it is simply a local project. If you want to share the project with others, you need to push it to a centralized code management system (remote repository).

If you don't know Git, what I used to do was compress the project, give it random names, upload it somewhere, and send the link to others to download and continue editing. Just imagine how difficult it would be to exchange information if each person made multiple edits in a day. Not to mention that they could edit the same code that we were still working on.

Github or Gitlab are two popular names that help you push code and share it. For example, after committing, you can push the code by using the push command.

$ git push

But before that, Git needs to know which remote repository your local project is associated with. Github or Gitlab? What is the address?... Don't worry, when you create a repository on Github or Gitlab, they will guide you step by step.

For example:

$ git remote add origin [email protected]:tonghoai/demo.git

After that, push the project to the remote repository.

$ git push -u origin main

[email protected]:tonghoai/demo.git is the remote address of the project. Setting up the remote repository only needs to be done once, and then you just need to push whenever you create a new commit to push the latest code to it.

Git helps with collaboration

Working in a team always requires more complex processes than working alone.

When you are the only one working on a project, you can freely add, edit, delete, and commit changes, creating multiple versions and pushing them to the remote repository. Now, when someone else joins the project, the first thing they need to do is to get the remote repository.

$ git clone [email protected]:tonghoai/demo.git

Immediately, the project is pulled into the demo folder. Just open it and you can start writing code.

But before you start writing, you tell them "I just pushed new code, pull it." pull is the action of pulling the latest changes from the remote to the local.

$ git pull

If you're lucky, you will successfully pull the code, but if any errors occur, congratulations, you have entered the most complex workflow on earth!

Git has an effective mechanism for resolving code conflicts when working in a team. However, I won't mention it in this article. If you are new to Git, take the time to understand how Git works before trying to "tame" this mythical creature. If you have any questions, feel free to leave a comment below the article!