Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 975
  • Last Modified:

TFS Branching and Merging Beginners Question

Hi,

We are using TFS and believe we need to use branching and merging.  We are 2 developers working on one website, we are in 2 geographical locations and are using www.visualstudio.com to host our TFS.  We want to keep the main trunk as an exact replica of the production website.

Our plan is for every new sprint (monthly approx.) we will create a branch called “website-sprint001” etc.  We will work on the sprint in our separate locations and checkin our work to the branch periodically throughout the sprint (month) to in affect save the code so the other can see it.  When we are happy with the final code we will merge back the trunk and  release to the production website.  Is this the correct use of branching and merging?  Is there a better way to handle our situation?


Thanks

nutnut
0
nutnut
Asked:
nutnut
  • 4
  • 2
1 Solution
 
evilrixSenior Software Engineer (Avast)Commented:
>> Is there a better way to handle our situation?

Yes, don't use TFS, use Git. Not only was Git designed from the ground up to be a distributed SCM, it is also incredibly lightweight in terms of branching. In fact, the Git ethos is to branch for each and every change and only merge back to the main-line when a change is read.

The other thing with Git is both you and your colleague will have your own local copies of the repo so you have redundancy. It also means you can commit changes locally so you have a way to track and revert your local changes. You can both push to a "truth" repository when you are happy with your changes.

If you need more convincing, I'd recommend you watch this.
0
 
nutnutAuthor Commented:
Thanks doesn't answer my question though
0
 
evilrixSenior Software Engineer (Avast)Commented:
Well, it does answer "Is there a better way to handle our situation?", which was one of the questions you asked :)
0
Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.

 
nutnutAuthor Commented:
Yes that is a good point it does, but we are commited to TFS and cannot change
0
 
evilrixSenior Software Engineer (Avast)Commented:
Understood and fair enough. Still, it's worth watching the youtube video when you have a moment, for no other reason that (a) it's hugely entertaining and (b) it'll make you re-think your world-view on how an SCM should work.

Other than what, I wish you good luck with your question.
0
 
evilrixSenior Software Engineer (Avast)Commented:
Oh, sorry - just one more thing I should have mentioned, there is a Git-TFS bridge that would give you the best of both worlds. In other words, you could use Git as a local and benefit from all that it offers as an SCM and you could push to your TFS server as the "truth" repo. This is something that a lot of people who are forced to use SVN do (git comes with an SVN bridge). Just something to consider.

This is probably also worth a look.
TFS Now Integrated with Git

Just thought I'd mention these in case you might find it worth something to look at.
0
 
ambienceCommented:
Well that is certainly one way to set it up but somehow I get a feeling that you are kind of over-protective of the trunk :)

Whether thats a good setup depends for example whether you are using TDD or otherwise have good test coverage. This allows you to keep adding to the trunk tested code. Continuous integration is even better.

Based on experience there are at least two problems that may arise

a) Some issues only come up when everything is brought together and everyone working in isolation necessitates further testing and bug-fixing after bringing it together.

b) I ran into this situation once when I branched code, did quite some refactoring and new stuff but then it was decided that only some of the stuff would go in the trunk. BUT ... it just wouldnt work because of the refactoring. I realized that it would have been better to merge the refactored code and then add new features. The solution was manually redo the stuff working on trunk (horrible).

Refactoring is the heart and soul of agile and the way I see, your suggested setup would only hinder it not make it any easier.

I would say that its probably better to branch after each release and have everyone work on the branch. When it reaches maturity tag it and move to another branch. If you need to release patches for previous branches then required code can be reverse merged.
0

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now