How does code formatting affect git conflicts?

Question

git

Why do teams that develop with git have certain rules for customizing the code editor? How do they affect git conflicts? (Let's say there are tabs or spaces, their number)

Answer 1

it's not so much due to git conflicts as it is to one style of code on the project. Every developer likes to write code in a certain style. Imagine the horror in the files when a team of 10 developers write code each in a different style. And if there are hundreds or thousands of developers on the project?
It will be PPC. And a couple of days ago I got such a project for revision. There is no single style. Who wanted to write like that. Therefore, they came up with some standards for writing code.

Answer 2

Why do teams that develop with git have certain rules for customizing the code editor?

I've never heard before that this has to do with using Git.
I think this has nothing to do with conflicts (directly), it's just that tabs in different editors look different and not infrequently "4 spaces" and "Tab" are not the same thing, even visually. For example, in the default VI(M) editor, "Tab" looks more like 8 spaces than 4.
Also, some languages ​​may be indent dependent, Python for example, and different indentation options may give unexpected behavior in some cases.. In general, it 's
common to use "4 spaces" instead of Tab... many editors can replace "Tab" with "4 spaces"...
Well, when everyone writes "in the same style", the potential number of problems, incl. in the future, for example, when analyzing the source code by machine, it will be significantly reduced.

Answer 3

No way.
This requirement does not apply to the git, but refers to internal standards for coding.

Answer 4

In fact, there are a couple of points in this that are important for working in git, and not only.
I'll try to tell you with an example:
We have a function like

function parseData({options = {}, lang, info, test, data, ...other}) {
}

Then 2 developers make changes to it
1)

function parseData({options = {}, lang, info, test, data, data2, ...other}) {
}

2)

function parseData({options = {}, lang, info, test, data, info, ...other}) {
}

we will have conflicts, in case of formatting such, there will be less problems

function parseData({
  options = {},
  lang,
  info,
  test,
  data,
   ...other,
}) {
}

also one more thing, the fewer lines of code we fix the better from here, for example, a comma at the end of an object is a good thing:

const data = {
  attr1: '',
  attr2: ",
}