0

I'm the technical lead for a small company (6 developers). We currently use SVN and we're slowly porting over to Git, after everyone gets their training.

Currently our clients are the ones who "pull the trigger" on branch integration. Meaning that some module or feature is built and then, that feature sits in a branch until the client asks that it go live. When it goes live, we merge the branch into a staging environment and do testing. Then once the testing confirms everything is working as it should, we then merge those changes into the trunk for the live push.

It's done this way because often we have a lot of parallel development and often requirements are always changing on the fly. So, to isolate and control what goes where, we put each module or feature in its own branch.

For a long time we've been having issues for managing branches. So, for example we might build a branch with feature A. Six months will go by and finally the client or the development manager will want to move that change ahead, if either of them remembers. This is where my problem is. What are some ways I can keep track of what branches have been merged? or not merged? A centralized way of keeping an eye on all these changes.

This can be a challenge to manage, because often as a lead at my company, I'm required to do project management, code, code review, integration on several platforms. The leads here are not silo'd, we're required to be part of all development everywhere. So often, at any point I'll have up to 7-10 different items on my ToDo list, and integration and branch management can slip through the cracks.

|improve this question
  • 2
    The way I've used it, we remove branches after they get merged into trunk. That means if a branch exists, it has not been merged in. – Philip Dec 12 '18 at 21:13
  • SVN records merge information, so it knows if something was already merged or not. – Andy Dec 13 '18 at 2:08
3

If you have a lot of parallel development consider using a Master branch and feature toggles.

It does require some extra discipline to ensure that the build works (even if the feature toggled code is incomplete) and to create, use, and then later cleanup the feature toggles. This can be offset somewhat by having static analysis tools and automated tests to both prove functionality works, but also to ensure its unavailability when toggled off.

The benefits though are that merging is a non-issue, because there are very few branches and those that do exist are merged quickly. Additionally this removes much of the branch management too. It also decouples deployments from feature releases. This can be a very nice sell to your clients/marketing department assuring them of both stability, and usability enhancements as new features can be disabled if they have unforeseen issues.

If you have a risk adverse environment or need to support several release lines, use the branching mechanism to spin off a release branch. This branch can have incomplete, or non-releasable features removed from it. This is fine as the branch will never be merged back into the main branch. Defect fixes can be engineered on the mainline and cheery picked across to the release branch.

|improve this answer
0

I could think of 2 ways to handle your scenario

  1. Delete the branch after merging: Once you have merged the branch, delete it. This way you will know that all the branches that are present are going to go live someday. delete-branch

  2. Rename the branch after Merging: If you feel you might need the branch for future reference, instead of deleting the branch, rename the branch. rename-branch

|improve this answer
  • I like the renaming solution, that's easy enough to do and would be relatively straight forward to implement. – ShinEmperor Dec 13 '18 at 12:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.