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:
https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/branching-strategies-with-tfvc?view=azure-devops
and here:
https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/effective-tfvc-branching-strategies-for-devops?view=azure-devops
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.
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.
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?
All,
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.
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.
Gated Check-In process:
https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/check-folder-controlled-by-gated-check-build-process?view=azure-devops
Check-In Locks:
https://docs.microsoft.com/en-us/azure/devops/repos/tfvc/understand-lock-types?view=azure-devops
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.
I think that's where VS checks if it compiles before allowing a check in.
Is that helpful or is it overkill?
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.
I welcome all suggestions and view points.
I will investigate your advice.
- 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.