Best practice advice for branching. Need some advice.

Copper Contributor

Hi All,


I have a question that I'd love to get some feedback on. I know that in general, keeping the number of active branches to a minimum is recommended, but what is the proper policy for having branches for individual projects?


Right now, we have one Dev branch and one Production branch. When I work on a minor change request that only takes a few hours, I don't create a new branch. When I work on a big project (multi-week), I shelve/stash the changes and not create a new branch. According to the ALM and branching strategy docs I've read, creating a feature branch for every project I'm working on and then deleting it after I've merged it back to the Dev branch is NOT the right technique, but it certainly seems reasonable that I'm reading too much into it.


Am I wrong in this assumption? Is it legitimate to create a new feature branch for every one of my projects as every other developer in my company would for whatever long term project they are working on as well? 


Current process

  1. Begin working on the code changes.
  2. Use the VS Shelve/Stash feature regularly to back up the changes
  3. Continue working the next day
  4. Rinse and repeat
  5. When project is done, check in to Dev

What I'm wondering about

  1. Create a feature branch /TFS/Features/Jason/ProjectXYZ
  2. Begin working on the code changes
  3. Check into the feature branch whenever
  4. Reverse integrate as necessary from Dev to Feature/Jason/ProjectXYZ
  5. When the project is done, merge from Feature/Jason/ProjectXYZ to Dev.

Any feedback would be appreciated. What's usually the best practice scenario for this sort of thing?

0 Replies