-1

My team is and I are examining to transfer from TFS to GIT:

The first question is how to prevent conflict on a file?
TFS -
1. check out file.
2. start working with the file.
3. commit changes.
if a person A is trying to check out the file while a person B is working on it than TFS will prevent it and will prevent a conflict.

GIT -
1. pull file from remote repo to loacl repo.
2. start working on the file.
3. commit to local repo only.
it is not a problem to check out a file while some one else is working on it. because it all happens on his local repo.

to me git looks much more complex. what do you think? what is the best way to work with git?

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
noah lubko
  • 99
  • 2
  • 10
  • You resolve conflicts manually with git. This is a large topic, too large to answer in a question here. I suggest reading some introductory text about git. – Jonathan Hall Aug 21 '18 at 09:02

2 Answers2

2

TFS will prevent it and will prevent a conflict.

No, it doesn't. It might prevent conflicts with the file, but it will result in conflicts between colleagues. For example one person checking out a file and then going on a three week holiday, causing you to have to dig down in the admin interface and unlock the file.

The lock-modify-unlock model is outdated and doesn't scale well. See also Source Control - Lock vs. Merge?. If you need it, chances are that either your development practices or your code base are suboptimal.

I'd say: embrace the fact that you'll have to fix merge conflicts now and then. Make note of when it happens, and see what you can change to prevent it in the future. Choosing a proper branching strategy and refactoring your code so unrelated changes don't have to be done in the same files will help a lot.

CodeCaster
  • 147,647
  • 23
  • 218
  • 272
0

Conflicts are a part of git. If you're making larger changes you create your own personal branch, make changes over a period of days. incrementally pull updates from the main branch into your personal branch and then finally merge back into the main branch. If you incrementally "rebase" the main branch onto your develop branch there will be minimal conflicts.

For smaller changes you will just run into conflicts, at which point you open your diff/merge tool, go through whatever conflicts there are and then commit the changes. (This is usually done by a senior developer if conflicts are non-trivial).

It's important to bare in mind that changes are on a line by line basis. So if someone edits line 50 and you add line 272, then there should be no merge conflicts and it should just combine those 2 changes. Conflicts only occur at times where the same chunk of code is changed by 2 people.

As a side note, I would recommend reading the git documentation and then perhaps starting with a "git flow" workflow which should help minimise conflicts

Prodigle
  • 1,757
  • 12
  • 23