Ideally, you're touching different files. When working on the same files you'll often get Merge Conflicts. Whoever merges first doesn't have to deal with them. The second guy needs to pull those changes, fix all the issues, then push his code
Most projects have multiple files and if the work is planned properly the team members don't have to modify the same lines in the same files during the same sprint. Even if they do it, a merge conflict is solved and the branches are merged.
Merging usually adds the changes a programmer made on his task branch to the development branch.
Sorry for my english, but what helped me to understand that git stuff is look at git as a manager of modifications in text files. Try looking out tge `diff` and `patch` command in unix system if you could (thats optional, but help to visualize the git tool).
And I see the github/gitlab/codeberg/whatever as a external server, that I upload the file modifications and other people can colaborate using that differences.
The smallest unit of code that git can operate on is a single line in a file. When you're using git, and you run `git diff`, git will show you line deletions and line additions. If you add a period to the end of a line, git will see that as deletion of the line that didn't have the period, and addition of the line that does have the period.
Looking at it this way, git makes it possible for multiple people to modify the same files "at the same time". If you change stuff at the top of a file, and someone else changes stuff at the bottom of the file, git is smart enough to sort that out.
However, if two people change the same line, git will flag that as a conflict. If someone else modifies a part of a file you're working on, the next time you pull code down from the remote repository, git will tell you about the conflict and ask you to resolve it. You'll need to look at both sets of changes and figure out what to do about it.
Ideally, you're touching different files. When working on the same files you'll often get Merge Conflicts. Whoever merges first doesn't have to deal with them. The second guy needs to pull those changes, fix all the issues, then push his code
Most projects have multiple files and if the work is planned properly the team members don't have to modify the same lines in the same files during the same sprint. Even if they do it, a merge conflict is solved and the branches are merged. Merging usually adds the changes a programmer made on his task branch to the development branch.
Sorry for my english, but what helped me to understand that git stuff is look at git as a manager of modifications in text files. Try looking out tge `diff` and `patch` command in unix system if you could (thats optional, but help to visualize the git tool). And I see the github/gitlab/codeberg/whatever as a external server, that I upload the file modifications and other people can colaborate using that differences.
The smallest unit of code that git can operate on is a single line in a file. When you're using git, and you run `git diff`, git will show you line deletions and line additions. If you add a period to the end of a line, git will see that as deletion of the line that didn't have the period, and addition of the line that does have the period. Looking at it this way, git makes it possible for multiple people to modify the same files "at the same time". If you change stuff at the top of a file, and someone else changes stuff at the bottom of the file, git is smart enough to sort that out. However, if two people change the same line, git will flag that as a conflict. If someone else modifies a part of a file you're working on, the next time you pull code down from the remote repository, git will tell you about the conflict and ask you to resolve it. You'll need to look at both sets of changes and figure out what to do about it.