Avatar of Babak Sekandari
Babak Sekandari
Flag for United States of America asked on

Advice on Getting Started in Version Control for a Two Programmer Project

   I’m a programmer working on ASP.NET code in Team Foundation Server and Team Explorer.
   I’ve usually worked on projects alone but this time, however, there are two of us on this project, me and a second programmer.
   I’ve only ever used version control for myself and now I need a strategy so that me and the second programmer don’t interfere with each other’s work, especially if we need to make changes to the same file.
   I’m reading through the Azure DevOps Services documentation such as the ones here:
and here:
  Unfortunately, the documentation doesn’t seem to answer the questions I have. For example, according to the “Start with a simple branching strategy” section for the “main-only” branching strategy, do both programmers work on the main branch? If so, what if there’s a conflict when we work on the same file, or worse, the same method?
   Does a programmer put a lock on the file to prevent that from happening? Our managers and supervisors have told us to figure this out between the two of us.
Should there be a branch for each programmer? In this case, there’d be the main branch, then a sub-branch for me and another branch for the other programmer?    Then code would get merged into the main branch. Is that the recommended way?
Finally, for a small two man team like this, is Team Explorer the better way or should we perhaps consider GIT as the repository. In that case, would we be using TFS with GIT?
   Please advise on how I should get started.
Thanks in advance.

Version ControlASP.NETAzure* Team Foundation ServerDevOps

Avatar of undefined
Last Comment
Babak Sekandari

8/22/2022 - Mon

You can only work on one file in parallel, when either

- the files is to big and you didn't follow the Separation of Concerns principle
- your requirements are not clear and your chosen development management strategy did not react accordingly

Normal work, where you edit something at the beginning and the other developer at the end of the file doesn't require locking as it is not parallel. And this scenario is handled by the used code repository software.

When you don't know how to use ADO or git, then you should look at SVN and agile (scrum) development with more than one daily standups. SVN is easier to handle and understand - drawback no distributed repo - and when you're new to this, then the most important factor is to talk as often with your coworker about what your actually working on and what you'll do next.
Paul MacDonald

There is only one branch, until someone creates another.  A branch is a deviation in the anticipated direction the code is taking, and is created so it doesn't interfere with the code in another branch.  You might branch the project to see if a particular UI is better than the one you started with.  You end up with two versions of the project, each in its own branch.

Generally, you would not have two programmers working in the same file at the same time.  Rather, when one programmer is done working on a file, she will check it in so other programmers can update their code with those changes and allow someone else to have access to it.

Babak Sekandari

Hi Ste5an,
re: "You can only work on one file in parallel, when either . . ."
Since we've started with a .NET Core 5 solution that has the ConfigureServices method and the Configure method in the Startup.cs for inversion of control and dependency injection, it will be necessary to configure it.
For example, what if I want to add configuration for a Microsoft Graph service and the other programmer wants to configure those methods for dependency injection for a database which he has scaffolded to a model? We might end up working on those methods in parallel.

Hi Paul,
In our case, would labels be better than branches?
TFS and Team Explorer allow a file to be checked out to multiple people. Then, when checking in, there can be a conflict. Should we put a lock on a file when someone checks it out?

For small projects like this, is GIT easier than Team Explorer?
The reason I ask is because I see Microsoft documentation statements such as this:
Unlike Git branches, which are repository-scoped, TFVC branches are path-scoped and therefore not as lightweight.  

Experts Exchange has (a) saved my job multiple times, (b) saved me hours, days, and even weeks of work, and often (c) makes me look like a superhero! This place is MAGIC!
Walt Forbes
Paul MacDonald

"For small projects like this, is GIT easier than Team Explorer? "
I don't think so, but YMMV.

"Should we put a lock on a file when someone checks it out?"
It's typical only one programmer gets to check out a file for editing.  Other programmers will have a copy of the last version they pulled, but should always "get the latest" to see if any changes have been made to other parts of the application.  In an environment with only two programmers I would expect the two to talk to each other about changes in the code, but in larger environments that may not be practical.

Babak Sekandari


I've had very few projects where users are NOT working on the same file at the same time.
Items like ConfigureServices, utility functions etc...

I'm in the process of moving over to GIT (mainly because of the lighter weight branches), but all is currently on TFVC.
Either is fine in this case, I would stick with TFVC if that's what you're used to.  Just keep in mind the MS themselves seems to be pushing everyone HARD into GIT.

I 100% would NOT apply the check in locks.  Any time you check in, 95% of the time VS does a pretty job itself of resolving multiple changesets.  There's always conflicts that can happen that it will prompt you to eyeball and pick how it should be resolved.

Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.
Babak Sekandari

What about gated check in?
I think that's where VS checks if it compiles before allowing a check in.
Is that helpful or is it overkill?

View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.

To add... I have personally went through CSV and SVN, luckily avoided TFS. Unless you want the version control for video editing or similar, I would strongly suggest Git.

With Git, the "branch" is somehow different from those in CSV or SVN -- much easier, with less problems.

In my opinion, GIT is very good also for "one-person project". For the strategy, have a look at https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows (I really recommend to read that excellent book).

I am (as you) working with VS, and it supports Git. However, I prefer the standard installation of the tool from the https://git-scm.com/ , and using it as a separate tool.
Babak Sekandari

Thank you, Pepr.
I welcome all suggestions and view points.
I will investigate your advice.
I started with Experts Exchange in 2004 and it's been a mainstay of my professional computing life since. It helped me launch a career as a programmer / Oracle data analyst
William Peck