How I Would Learn a Git Commands (If I Could Start Over)

cover: https://www.monkeyuser.com/2021/time-to-merge/

Hey, fellow developers!

Let’s admit it. Coding in a team is like being in an adventure or action multiplayer game. Each person in a group owned unique skills and different tasks. But we are aiming for the same goal: completing the project deadline. Our coding skills are just some of the ones to achieve that; we should have good teamwork to enable multiple developers to work together. For that, we can use GIT.

And for that, if I could do it all over again, this is how I would learn Git Commands so that I will be mastering GIT. 🔎

Getting Started

It all starts with initializing a new repository using git init. This is essentially the birth of your project in the Git universe. Here's how it goes:

mkdir myProject
cd myProject
git init

Or creates a copy of an existing Git repository on your local device with git clone

git clone [Github or Gitlab Link (ex: "git clone https://github.com/github/training-kit.git")]

Once you have cloned a repository, you won't need to clone it again to do regular development.

Git Add and Commit

Think of your repository as a hotel. Your files are the guests that need to check in. That's where git add it comes into play. It's like the reception desk of your hotel. Files are staged here, waiting to be committed to your local repository. The command git add . Stages all files in the current directory.

But that's not enough. The guests need to be assigned rooms. That's where git commit it makes its appearance. It takes a snapshot of your code at a specific point in time. It's like the check-in process at our hotel. When you commit changes, you assign your files a room, a state they can always return to if necessary.

git add .
git commit -m "Initial commit"

But, everything has its own 'best practice', likewise git commit . In aspiring, we use format <type>: <subject>.

There is 4 type in this case, such as test (add test for the feature we create), feat (add feature), chore (add implementations that are not related to functionality), and refactor (refactor production code, make improvements to previously created code).

By writing good commits, we get benefits like making it easier to debug our code and the fact that code reviews get much easier.

Git Branch and Checkout

Imagine working on the same codebase as your team and constantly updating each other's work. Nightmare, right?

Enter git branch. This command lets you create a parallel universe where you can work on your code without affecting the 'main' universe (branch).

Let's say you're adding a new feature called. landing-page.

git branch landing-page

But wait, how do we enter this new universe? We 'checkout' to this branch using git checkout.

git checkout landing-page

Now, you're inside your newly created universe! Change, adapt, and improvise to your branch. Your main universe remains unaffected.

Git Push and Pull

In the end, we all need to come together. That's where git push and git pull shine. Once you're satisfied with your work in your branch, it's time to merge it back into the main universe.

We will merge into the main branch in the best practice way ✨

First, you add and commit your work.

Second, you push your branch into the local repository.

git push origin landing-page

Third, merge new requests of your branch into the main branch.

Forth, merge to main if only your teammates approve your work and there is no conflict between your branch and main branch.

Voila! Your new feature is now part of the main codebase, and your team can see it too.

On the other hand, git pull allows you to update your local codebase with the latest changes in main branch by your teammates.

git pull origin main

This is Your Curiosity Begin

#1: What If I Faced Conflict?

Just when we thought everything was going smoothly, we hit a storm. Two of my teammates worked on the same piece of code in different branches, and when they tried to merge their changes back to the main branch, Git flashed a terrifying message: CONFLICT.

Fear not, though, because I got you a solution.

Conflicts typically arise when Git cannot automatically decide which version to use while merging branches — when changes are made on the same lines of the same file, or when a file is deleted in one branch but modified in the other.

When a conflict occurs, Git pauses the merging process, allowing us to resolve the conflicts manually.

Identifying the Git Conflict

Git marks the problematic area in the file by enclosing it within <<<<<<<, =======, and >>>>>>> symbols. The version from the current branch appears before the ======= symbol, and the version from the merging branch appears after it.

I will give you an example with aspiring code. if we have a conflict in landing-page.tsx Git will show something like this:

<<<<<<< HEAD
    <h4 className="font-bold max-lg:text-center">
              Lorem Ipsum
              <span className="text-primary-600">aspiring.it</span>
    </h4>
=======
    <h4 className="font-bold max-lg:text-center">
              Kick Start Your
              <span className="italic underline">Internship</span> Journey in
              Tech Industry with
              <span className="text-primary-600">aspiring.it</span>
    </h4>
>>>>>>> feature-branch

Solution

Resolving a conflict involves deciding which version to keep and which to discard. We can keep one over the other or even decide to merge the changes manually. In this case, we might end up with:

  <h4 className="font-bold max-lg:text-center">
              Kick Start Your
              <span className="italic underline">Internship</span> Journey in
              Tech Industry with
              <span className="text-primary-600">aspiring.it</span>
  </h4>

Once we’ve made the decision and adjusted the code, we stage the file with git add and commit it using git commit.

git add landing-page.tsx
git commit -m "chore: resolve conflict between landing page and main branch"

And, you are done with conflict!

#2: I want to look at the commit history, How do I do this?

So, we have been pushing our code, resolving conflicts, and everything seems to be sailing smoothly. But now we have a new requirement: to take a peek at our journey so far. In other words, we want to look at the commit history.

Navigating through the Git commit history is as simple as typing the command git log.

and done! you will look at the commit history.

#3: Oh no, I am not ready to commit but I need to switch branches! How do I solve this?

We can say hello to: git stash.

The Concealing Act

The git stash command takes your modified tracked files, stages changes, and saves them on a stack of unfinished changes that you can reapply at any time.

Here’s how you can use it:

git stash

Now your working directory is clean, and you can switch branches, create a new commit, or do anything else you want.

The Reveal

When you’re ready to go back to your work, you can use git stash apply to reapply the changes you've stashed:

$ git stash apply
# On branch main
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   landing-page.tsx
#
no changes added to commit (use "git add" and/or "git commit -a")

Now you’re back where you left off, and you can continue your work.

Final

Once you’ve reapplied a stash and made sure everything works as expected, you can drop the stash using git stash drop

#4: I made a commit mistakes, can I undo this?

Absolutely! In Git, there are several ways to undo a commit. But, before you proceed, remember: you must be extremely careful when undoing commits, especially if you’ve already pushed your commits to a public repository. Here, I’ll guide you through two methods: git reset and git revert.

Git reset

The git reset command allows you to "move" the HEAD pointer to a previous commit, effectively "undoing" the commits that came after it.

git reset --hard <commit-hash>

In the command above, replace <commit-hash> with the commit hash you want to revert to. This hash can be found in the commit history, which can be viewed with git log. The --hard option tells Git to discard all changes made after the specified commit.

However, git reset --hard should be used with caution. This command will permanently delete any uncommitted changes and any commits that came after the specified commit. You can use the --softoption to keep the changes but unstaged them.

Git revert

If you want to undo the changes introduced by a commit but keep the project history intact, you should use git revert:

git revert <commit-hash>

Unlike git reset, git revert will create a new commit that undoes the changes introduced by the specified commit. This is generally safer and is the recommended way to undo commits if you've already pushed your changes to a public repository.

#5: Can I manage my project using Git?

Obviously, yes!

With Git, not only can you manage your codebase, but combined with GitLab, it becomes a powerful project management tool. You can read more about GitLab in my other articles here.

Here are a few standout features of GitLab that make project management a breeze:

#1. Advanced Project Management Features

In GitLab, you can use Issues to track ideas, enhancements, tasks, or bugs for work on your project. Issues can be organized via labels, milestones, and assignees.

The Milestone feature allows you to group issues into a list that should be completed within a specific time period.

Labels can be applied to issues and merge requests. They’re like tags that help you categorize your issues or merge requests with certain attributes.

#2. Monitoring Performance

GitLab provides detailed Analytics to keep track of your project’s progress and productivity. The Contribution Analytics breaks down every commit, merge request and issue comment, providing a detailed overview of project activity.

#3. Visualizing Progress: The Burndown Chart

GitLab’s Milestones page provides a Burndown Chart. It’s a graphical representation of work left to do versus time. This helps the team to understand if they are on track to complete the work within the given timeframe.

#4. Kanban Boards

The Board feature in GitLab is a more visual way to track the issue workflow. Issues can be moved from list to list, representing a change in their stage of completion.

Conclusion

And there you have it: your adventure through the universe of Git. From initializing a repository to managing conflicts and reverting mistakes, all the way to project management with GitLab. With this newfound knowledge, you can now navigate your way through any team project with confidence and ease.

Remember my analogy of the ‘Git hotel’ for a little more fun. The guests (your files) have come, checked in (Git add & commit), gone out to see the town (git branch), and come back to share their experiences (git merge). Some were confused about their room assignments (git conflict), but they sorted it out in the end.

Git is a powerful tool, but your team’s curiosity, cooperation, and dedication to learning will truly power your projects. With these elements in place and now with your mastery of Git, you’re ready to take on any coding project that comes your way.

Just remember to have fun on this journey! 🚀

And that’s a wrap, Thank you! 💖

I will appreciate your feedback 💬 & clap 👏.

If you want to collaborate, don’t hesitate to contact me at deyunarusmiland@gmail.com or through Linkedin ☕

References

Create a project | GitLab

Undoing Changes in Git | Atlassian Git Tutorial

Git Revert | Atlassian Git Tutorial

git stash - Saving Changes | Atlassian Git Tutorial

Book