👨🏼‍💻The Git Guide For Your First Day At Work

Introduction

Git is a high-performance, distributed version control system. It is created by Linus Torvalds for his own needs while developing the Linux kernel. It is a very good software, which is why it has become the most popular version control system.

There is a debate over “Which is better?” for almost every technology in the software world. We can argue for tens of hours about which operating system, which programming language, which code editor is better. On the other hand, we almost never come across a discussion topic such as “Git vs X”. This demonstrates the success of Git.

There are lots of tutorials on the Internet about Git; articles, cheat-sheets, video tutorials... This content has a different goal from them. It is created to help you on your first day at work and speed up your adaptation process.

Let’s Talk About You and Git

You have accepted a new internship or job offer, you are starting soon. You are aware of a version control system called Git, you are familiar with a few basic concepts, you have created an account on Github or Gitlab in the past, and you have pushed and pulled code several times.

On the other hand, if you didn’t use Git with a team, you may have questions about how to use this tool on your first day of work.

When working individually, we rarely encounter merge conflicts, we pay less attention to branch names and messages, and we don’t waste time by opening pull requests.

When working in a team, we start to encounter conflicts, and we start to see that we need to choose better naming and messages.

The focus of this content is to ensure you have a seamless Git experience on your first day at work. We do not aim to learn & follow best practices. Our main goal is a rapid adaptation process.

Preliminary note: Do not hesitate to ask questions of your colleagues. It is a shared responsibility of the company to inform you or direct you to the necessary training.

Git Interface Selection: GUI vs CLI

Git can be used directly from the command line or through some 3rd party applications that offer a graphical interface. The question of which is better is a topic of fun debate. But at the end of the day, it’s just a matter of personal preference.

For example, I mostly prefer to use the command line. But sometimes I use some 3rd party software and Git support for my code editor. Also, I was using a tool called LazyGit for a while; We can’t include it in either the GUI or the CLI category, it belongs to a different category called TUI.

What should be your choice?

If your goal is to learn Git, I recommend spending time on the command line. It’s the only way to truly experience Git.

If your goal is to quickly get started with Git at work, it probably makes more sense to opt for 3rd party software that offers a graphical interface.

Which 3rd party software should you use?

Use the software you feel most comfortable with.

• Most of the code editors and IDEs have utilities for Git. They’re pretty good for most operations, and they’re probably the best environment for quick adaptation.
• GitHub Desktop has a very practical and clean interface, and if your company also uses GitHub, it gives you a good experience with the notifications it sends.
• If you are looking for a more advanced, more functional application, you can have a look at SourceTree. I especially like the way it shows the Git history.
• You can also take a look at some paid tools such as GitKraken and Sublime Merge. Your company may have purchased a paid tool for the entire company.

Basic Git Flow To Follow

Let’s start with a general flow to follow when using Git, and see a few commands to gain familiarity. Later, we will continue by detailing this flow.

1. Switch to development branch: git checkout develop && git pull origin develop
2. Create a new branch: git checkout -b my-feature-branch
3. Commit when needed during development. This step may need to be repeated several times until the planned developments are finished, once the developments are complete, move on to the next step.
   1. git add .
   2. git commit -m “Add a blog post”
4. Make sure there are no conflicts, if any, and resolve them.
   1. git checkout develop
2. git pull origin develop
   3. git checkout my-branch
   4. git rebase develop
5. Push your work to Git: git push -u origin yourworkbranch
6. Open a Pull Request.

Now let’s continue by examining each step in detail.

1. Switch to the development branch

Our first step looks so natural, that it doesn’t need much explanation. However, if this step is skipped, minor problems may occur, let’s see through an example.

Let’s say you’ve developed a feature, pushed it to a Git server, and finished the process. If you immediately create a new branch to start developing a second feature, the branch you created will derive from your old branch. However, this is not the desired case, the desired case is to derive from the develop branch on the Git server. In order to see it more clearly, let’s examine the desired situation and the problematic situation with a graph.

After the work on branch-a is completed, it is desired to create a new branch named branch-b to start a new work. As you can see in the graph, the newly created branch named branch-b is derived from branch-a. But the desired situation was to derive from the development branch.

Does this create a problem? Sometimes yes, sometimes no. Here are a few examples of the situations it creates a problem:

• If branch-b is to be merged independently of branch-a, this problem complicates the process and requires additional intervention.
• In the future, it may be difficult to understand what has been done when looking back.
• It might unnecessarily waste other developers’ time by creating confusion in the code review processes.

Solutions to these problems and other problems you may encounter can always be found. You will definitely learn new solutions and techniques as you need them over time. However, as I mentioned at the beginning of the article, our goal here is to start contributing to the project as easily and cleanly as possible. Therefore, it would be better to proceed by solving minor problems that may occur in advance.

It is extremely simple to do to avoid this problem. Before creating a new branch, it is enough to go back to develop a branch with git checkout develop && git pull origin develop and create the new branch from there.

You are probably aware that “develop” represents the name of the development branch in your project. Different naming may be used in different projects, verify and continue with the appropriate name.

2. Create a New Branch

We need to create a new branch for the improvements we will make. It is extremely important to have a good naming when creating a branch.

How to name a branch?

There are different approaches here. If you do research on the internet, you can come across much content claiming that some different approaches are more accurate. Usually, the goal is to make the following few items part of the branch name:

• If it is a job opening as a ticket on JIRA or a similar application, the relevant id value,
• A categorization word according to the type of development. (feature, bugfix, hotfix, etc.)
• A few words summary of the work done

Also, we can not use spaces in the branch names, so we need to use a character like “/”, “_”, “-”. My personal preference is to use “/”, but it is possible to come across others. Let’s look at some sample branch names:

• fix/11787/extension-warning
• 42483-color-tests
• feat-custom-endpoints

We could multiply examples, but this is enough to see that there are different styles of naming. Let’s skip the discussion of which one is right and which one is good. I suggest you look at the naming pattern the team is using and stick with it.

Also, if you are working on a relatively mature project, this naming pattern may have been documented somewhere. In this case, you are extra lucky, you can follow the document.

3. Commit when needed during development.

Commit your developments as atomically as possible and with a good message.

Imagine, you are looking at a commitment that was made 2 months ago. Thousands of lines have been changed with the message “Some changes…”. It is extremely incomprehensible what was done in this commit, and which code was added/deleted.

In order not to create difficulties for yourself or your colleagues in the future, use atomic commits with a good message.

You will get very good results if you pay attention to the following few points while writing a commit message:

• Just commit the relevant changes. Let’s say you saw a performance issue in a different method while developing a feature and you fixed it. Do not commit this work together with the main feature you developed. Make sure that your work is within the scope of the relevant branch names and commit messages. Use different commits and/or different branches if necessary.
• Use frequent and small commits. Large commits are also difficult to track. It is very difficult to understand what is done in a commit that contains code on many different topics.
• Do not commit incomplete jobs. It is important to get the balance right when trying to use frequent and small commits. The project should be consistent when returning to any commit in the project history. Do not commit incomplete or non-working work.
  A little tip: If you notice that you have committed the previous change early while you are working, you can tidy up the situation by using “amend commit”.
• Do your tests before you commit. Run the tests in your project, if there are places that need to be tested visually check them, and compile the project if you are working with a compiled language… Make sure that the change you make does not harm the rest of the system so that another software developer who wants to go back to the moment you commit will not have unexpected problems.
• Write a good commit message. There are many details on this subject, let’s continue in a larger area below.

To write a good commit message, it is necessary to follow a template and fulfill some criteria. There is an approach that I think can be applied to any project and will yield good results. The explanation of the model is here: https://cbea.ms/git-commit/ I suggest you read it when you have time.

Let’s look at a few “good” commit messages:

• Add logout button
• Remove unnecessary condition
• Fix showing the wrong currency on the cart page

As we have seen in the examples, sentences should be made as short and imperative as possible. At first, this may seem a little strange, because in everyday life we do not act this way when we speak or write.

Let’s take a look at the formula that makes it incredibly easy for you to write a good commit message, it is from the blog I shared. While writing, we imagine the following pattern:

“If applied, this commit will remove unnecessary condition”.

If the “If applied, this commit will…” statement is deleted, the commit message becomes ready.

In addition, although not very critical, there are a few more points to consider in order to keep the quality high. Capitalizing the first letter of the commit message, writing a good description in the body field when necessary, not putting a full stop at the end of the message… There are more matters and details, that’s why I recommend you to go to https://cbea.ms/git-commit/ at a convenient time and read it. :)

If you’ve noticed, I didn’t say “do as your team does”. If your team follows a good methodology for this, of course, you should follow it. However, sometimes teams do not take this topic seriously enough and there may not be good practices to follow. In this case, repeating the old will only increase the existing clutter. I recommend you invest in the future of the project by following good practices.

4. Make sure there is no conflict, if there is, resolve it.

Git works very smartly in most cases. It combines the code changes and creates a whole. If you and your teammates make changes in different files/lines, you don’t have any conflict.

But there are some scenarios that Git can’t handle. If you and your teammates have changed the same lines of a file, choosing which change should take effect is a really hard task. Also, sometimes, beyond just choosing one of the two changes, it may be necessary to keep both or to remove both and write new code.

Who Should Resolve Conflicts?

It is the developer’s responsibility to combine the written code with other codes. If necessary, you can ask the developer who wrote the conflicting code for help.

These are just my opinions. If you wish, ask your teammates the question, “If there are conflicts, do I need to fix them?”. If they say it’s not necessary, skip this step.

Resolving Conflicts

The tools you use warn you if there is a conflict.

• If you use merge/rebase commands to merge code on your computer, Git warns you about the conflicts and asks you to resolve them.
• When opening a Pull Request, you will be shown a warning about the conflict. (It is possible to open a pull request, but the buttons to confirm the pull request are disabled, they will available when the problems are resolved.)

To resolve such conflicts; you can merge the branch that is planned to be merged into your own branch.

git checkout develop        # switch to develop branch
git pull origin develop     # pull remote develop branch to local
git checkout my-branch      # go back to working branch
git rebase develop          # combine codes with rebase

There is more than one way to do this, but I suggest you follow these 4 steps to see the progress clearly.

You can also prefer to merge instead of rebasing. Although my preference is generally rebased, this is not an agreed-upon choice. You can continue by looking at the project history or asking experienced teammates whether to use a merge or rebase.

For conflict resolving, I suggest using VS Code. It has the best experience I’ve ever seen for resolving merge conflicts.

5. Push your work to the Git server.

Once the developments are complete, we can send them to the server. If you are using the command line, it would be good to push it via this command: git push -u origin yourworkbranch.

If you’re wondering why we use the -u flag…

By using the -u flag, in addition to pushing your code, you also add a reference of the remote branch to your local branch. This is called upstream. If you run statements like git pull without specifying the branch name, the branch name set as upstream is used. If the upstream is set incorrectly, there may be cases such as fetching files from the wrong branch or sending files to the wrong branch. When not set at all, Git warns you that you need to set up an upstream. Normally you need to use an extra command like git branch — set-upstream yourbranchname origin/yourbranchname to set-upstream. -u is a helper parameter to skip the setting upstream step.

6. Open a Pull Request.

The work is done, now you can open PR. It would be great if you pay attention to the title and description when opening a PR. In many organizations the description field is provided to you as a template, you should follow it.

After opening a PR, regularly check for comments and feedback on the PR you opened. With a well-established Git infrastructure, you should be notified if something happens to your PR. If you do not receive notifications, it is useful to check sometimes.

In addition, there may be some developments that you want to add/change after opening the PR. In this case, it is enough to switch to your branch, make the changes you want, and push it again. New commits to your branch automatically become a part of the PR.

Using Git Cannot Be That Strict

Seeing this headline after saying “follow these steps” throughout the article may seem a bit strange, but that’s how the real world is. It is impossible to go by following a flow all the time in daily life. Let’s look at a few example scenarios:

• You may need to start another development before completing one.
• If you are working on a feature, you may want to use Git to back it up even though it does not finish.
• Even if your work is unfinished, your teammates might need a completed part. They may ask you to send it to Git, so they can have the current version of your work.
• You may want to change an old commit message you sent when you complete the work. Sometimes you may want to combine 4–5 commits into a single commit.

In such cases, it is necessary to have a more flexible working model by making use of the other opportunities provided by Git.

The bad news is that you can’t get that flexibility by reading from a text.

The good news is that you don’t have to worry about this situation, you can have the flexibility I mentioned in a very short time by doing little research while working.

The 2 commands that I use the most and make my life easier:

• Rebase: It should not be considered as an alternative to merge only. By using rebase, you can merge old commits, change past commit messages, destroy some commits directly, and much more.
• Stash: It is a command you can refer to when you want to store your work somewhere without committing it. It’s also very useful for migrating work to a different branch.

Keep these commands in mind, you can Google it whenever you need it.

Conclusion

Finally, as I emphasized at the beginning of the article, do not hesitate to ask questions. Most of the problems you will encounter can be solved in a few minutes by an experienced developer.

After asking a few questions and practicing a bit, you’ll start to have a very comfortable Git experience. ✌🏻

References

Git

How to Write a Git Commit Message