Prevention of merge conflicts when working with the team

Want to go quickly, go alone, want to go away, go together .

Surely you – the developers who are sitting in front of the computer screen reading this ugly article of mine have all heard the above statement. Unless you are a loner who specializes in acting alone in freelance circles, no matter where you work, there will be colleagues and team members working together with you. And the most frightening thing for programmers when working together is probably merge conflict – conflict when combining code.

Why should be prevented? If everyone has experienced it, you will understand, the resolution of conflict is a process that not only takes a lot of time but also makes it easy to generate unintended errors. There have been many times when “your feature has run well, my code is also complete, but when it comes back to being an error both, then who is the error? “. Therefore, how to prevent conflicts is that things need to be considered from the beginning.

First things first

So what should farmers do?

First, open the computer and read this article immediately. Oh, but reading it, skip it.

Step 2, after reading it, if you see which one is applicable, you should apply it immediately. From the painful and bloody experiences of myself when working with the 1-member team as well as the corporate team, I thought that I took a little time when starting the project to agree and setup for this process. Will help you avoid unlimited times conflict after working together. Since I applied these rules, the number of product breaks has been only because a careless commitment has dropped significantly, to almost zero .

Okay, let’s start.

Problems about differences

I will list some common conflicts during the software development team:

• Indent conflict (tab or space, 2 or 4, …)
• Line-break conflict (CRLF or LF), this or conflict between win (CRLF default) and linux (LF)
• Formating conflicts (whether spaced or not, downstream or not, …)
• File conflicts arise during runtime (log, data, …)
• Conflict config
• Conflicts involve not production-ready code

Resolve the difference

My following precautions only prevent code-related conflicts, while business-related conflicts such as duplicate features, or force majeure like features on the same location, … you have to solve yourself. decided.

Step 1: Unify the convention

Encoding convention , or code writing standards, are general rules when working with a particular language or framework. The fact that your whole team follows a unified rule will certainly make your code easier to see, read, bright and easier to understand for everyone on the team. However, here I will not mention deeply the rules of each programming language, but will only ask you to agree on some basic rules related to coding style to work together without conflict. .

• Tab or space? This is a small problem that turns out to be very big. Because almost every code has an indent , how to use indent has a profound effect on your code base. Editing indent can sometimes lead to a change of the base code . I always let the whole space .
• Indent 2 or 4 (or even 8). As noted above. Remember this indent size you don’t need to follow any guy, as long as your team agrees with a standard that is easy to see. I choose 4.
• Rowing rules.
• Spacing between variables, values, …

These rules are now mostly standardized for each language, and more importantly, the IDE also supports auto-formating according to these standards. The unification of your coding convention will make it easier to avoid even not edit the code and still commit new because of the down line or warning.

Step 2: Define the .editorconfig file

After you agree on the coding convention for your project. The next step is to set up an environment for IDE’s people in the team to follow the same standard, avoid coding this machine to a beautiful person who is going to be confused.

Editorconfig is a definition of coding style adopted by many IDEs. It allows IDEs on different machines (or different IDE’s) to recognize style rules at the project level. You can read more on its homepage to know if your IDE has support available or need to install a plugin.

Editorconfig will do the task to tell IDE what your project is using indent, how much it is, down to what line, … Below is a file .editorconfig form you set in root project:

This file defines the indent, linebreak and charset for files in the project. In addition, there is a section about removing extra space and empty lines at the end of the file.

Step 3: Auto format / linting code

After you have successfully set up rules for the IDE, this step is to setup the IDE plugins related to lint code / auto format code.

Note : This is a double-edged sword. On the one hand, it helps your code achieve high consistency and easier to read and clean. On the other hand, it can make the conflict problem worse if the setup is not standard.

Why is that? Because setting up lint code and standard code format will help you prevent 99.99% errors related to syntax code when the IDE has analyzed the code and recognized the problematic syntax. In addition, the auto format code also helps the team work together to avoid distance problems or difficult to read code.

However, the auto format is quite dependent on the IDE. So if your team uses the same IDE, the same auto format setup will promote the best performance, since the auto format of everyone does not affect each other. If everyone uses IDE differently, be careful with this feature and look carefully when using it.

If you do not want to setup auto format code, then you can use only lint code tools like eslint (with JS) or PHP code sniffer (with PHP), … also. These tools help provide the convention coding warnings for your code. Thereby helping you to repair and unify the whole team more easily.

The tool format code JS or PHP: prettier , phpfmt , …

Step 4: Unify the process of working with Git

One of the most important but often overlooked small and medium teams is the process of working with Git. Although everyone knows how git works, commits to how to code, push pull, but people rarely pay attention to how to work with git properly.

A sample workflow with git that I find quite reasonable is Git flow . You can read this article to learn more about how Git Flow works. Or a more understandable and intuitive Vietnamese article here

This is a process that allows you to develop product features simultaneously, avoiding errors and very modern. I see this is a very suitable process for you to make app, mobile or release version, but with web systems – changing fast and continuously, managing version is not meaningful at all So follow some Git flow rules. You can refer to this article for flow related to short-lived branch.

For example: your project should only have 1 starting point , that is, every feature comes from the stable (master) version and will end at master. During this development process will be merged to unstable branches like dev, staging, … and must update the code from master before pushing or creating merge requests.

The fact that your project has such a defined update stream will help avoid conflict when developing, not only between team members but also between features.

Step 5: Design the .gitignore file very carefully

This is an extremely common mistake by new graduates or even longtime developers when not writing the .gitignore file carefully.

.gitignore is a file that contains the links, directories and files that git ignored . These files will not be committed to git repo but only exist on each running environment.

The following are very interesting files causing conflicts due to non-standard setup .gitignore :

• Log file (error, info log, …)
• Config file (database config, url config, …)
• IDE file (project file)
• Runtime data file (upload, temp file, …)
• Dist file (app file after build)

These files, if not carefully considered, can cause not only a confict code between a member of the team but also a production system error. So pay special attention to the .gitignore when creating the project.

A tool that creates a very powerful and complete .gitignore file is gitignore.io . Or you can refer to the sample .gitignore files at this repo: github / gitignore

This is an example of .gitignore with your project

Conclude

Summarizing the article, I have provided you with some guideline so you can refer to study and improve the performance of your team. These are just some methods of preventing conflict arising from human reasons. If there are conflicts related to business or function, then your task must be solved.

I often share with everyone that: “My biggest contribution to the old XXX company is not YYY product, but the group work process I drew from the price to be paid for time and island breaks ”. Hopefully, through this article, you will save a considerable amount of time and effort for silly conflicts with your team.

Source : https://techtalk.vn