Software versioning best practices

I'm working in VB.NET, and using BitBucket for offsite source code storage only at this point.

One of my projects is about to be released to a much larger audience, which will result in more requests for that utility. Each of those utilities has some form of customization - generally business rules type of thing, but often revisions that should be added to the "main" source. I would like suggestions or best practices regarding the correct way to create my new projects, based on the source, so that I can better manage updates, revisions, feature additions, etc.

I've read quite a bit about branches, forks and merges, but I'm not entirely sure how this would be handled, especially since some of the revisions should NOT be saved back to the main source code (i.e. the specific business rules), while other items (feature requests, bug fixes, etc) will almost certainly need to be saved back. I'm comfortable pulling down the project, and saving it back to the BitBucket server, but that's about the extent of my interaction.

One example scenario would be this:

I've created a utility for CompanyA, and have deployed that project as Version1. That project contains all of my common source code, along with a module to contain the specific business rules for CompanyA.

CompanyB buys the same utility, with requests for revisions for specific business rules. No major functionality changes to this.

CompanyC buys the same utility, but asks for a major feature integration (perhaps email capabilities), and they also need revisions for specific business rules.

In my current process, I have been copying the project over to a new directory and maintaining specific versions. This works, but as you can imagine this will become a huge mess very shortly (I only have 3 now, but there are many more coming down the pipe). I have to go back and update all 3 projects now for code fixes, and that's obviously not going to work.

So my goal is to better understand versioning and such in general, and GIT and BitBucket in specific. Can anyone help me with this?
LVL 86
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jaime OlivaresSoftware ArchitectCommented:
My first hunch is that you need to design a good pluggable architecture, so you would write plugins instead of modifying your main codebase.  If you are working with .net, I suggest to read a bit about Microsoft Extensibility Framework (MEF)
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareAuthor Commented:
Thanks for your input Jaime. MEF looks very capable, and it seems as if it's a good tool for something like this. Unfortunately I'm not able to implement something of this nature, since much of the codebase is provided by others, and I cannot change it - it must remain as-is, and I have to work around that. That will change as time moves on, but for now, MEF is not feasible.

I'm pretty well stuck with the methods I described above - using version control to maintain different versions with a common code base, where I build on that code base. My intent is to keep the original source "clean", while still allowing me the latitude needed to make changes and such for specific customers.

Is that doable? Seems like it should be, and that I should be able to "branch" off that source to create my own. I realize the main code base could change, and that could be catastrophic - but the code base hasn't changed in many years, and isn't about to any time soon. The company is rewriting the application, and when that happens I believe they're writing in the framework for more intelligent add-ins. But for now, I'm stuck with what I have.

Thanks again - any further suggestions?
Jaime OlivaresSoftware ArchitectCommented:
Branching seems like your best chance: it won't modify the trunk code at all and the branches will stay there for further use or revision. Also, a branch will be clearly related to the main code (trunk) at some specific point of time, so if you keep modifying the trunk, that won't create a discrepancy with the branches.
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareAuthor Commented:
Thanks again, your input is much appreciated.

So if i branch off the trunk a few times, and then I modify the trunk code, would that modification flow "upstream" to all my branches? Sorry if this sounds like a newbie question, but I am quite a newbie to using source code control for this sort of thing ...
I cannot speak for BitBucket. For Git, the trunk and the other branches are equal in principle. Actually, there is no strict abstraction known as a branch. The status of the project in one time is captured as a commit point that describes everything. The commit point may have one (if it is another step in the same branch) or more parents (if there was some merging with other branches).

You can think about the branching model of Git as about a acyclic graph structure -- commit points being the nodes, references to parent nodes being the edges. The named branch is simply a named pointer to one of the commit points. You can easily branch from any commit point in history, and you can easily merge two (and even more at once) branches together. The merging mechanism is very good.

Have a look at ProGit book by Scott Chacon, chapter 3 (

I did not try the approach where separate branches are dedicated to a single feature with a history and with the planned future. However, it should be quite possible. Branching and merging is really easy in Git. And it is difficult to break anything so that it cannot be repaired.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Jaime OlivaresSoftware ArchitectCommented:
So if i branch off the trunk a few times, and then I modify the trunk code, would that modification flow "upstream" to all my branches?
No, the branch would be associated to a trunk version in the past, further trunk updates won't affect your branches.
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareAuthor Commented:
I've been reviewing a bit more about Branching and Forking, and from my reading it seems they are very similar, with the exception being a Fork is a distinct copy/clone of the main source. This seems to be a better fit for me, as I need to keep those customer-specific features distinct in each code base.

Are you familiar with Branches vs Forks? If so, could you provide any further information?

Thank you both very, very much for helping me to better understand this. This is an area of my knowledge that needs quite a bit of fleshing out, and you're helping tremendously with that!
Forking (named that way say at GitHub) means cloning everything with read-only access -- including all branches.

Cloning your own repository to your own another repository is pretty the same, but you can also write back (commit to local repo and push to the remote one). In Git, you can limit cloning to a single branch. This way the local repo and the remote repository may finally look quite different.

So, in my opinion, you can think about many scenarios how to combine branches and clones (remote repositories). Your local branch may be the clone of a remote repository branch. This way, you may start limit your thinking to branches. The remote repositories will become local branches anyway.

If one branch is dedidated for implementing a single feature (or shared by all or some of the project specialised to the customers, or special for a single custome), each one project can have another branch that is a merge of several chosen "feature" branches.

I understand it it difficult to jump into the running train of the big project. Anyway, it is possible (with Git) simply separate chunks of related files with code and create separate git repositories. Then you can create another empty repository, add remote repositories for the related feature branches, and create another branch as the merge of local branches.

The good thing (in my opinion) with Git is, that you actually can start the wrong way (unintentionally badly designed branches and repositories), and you can still make it nice via later steps -- thing that is almost impossible (at least for me) to do with CVS or SVN). In other words, cloned or somehow derived Git repositories are easy to create, easy to transfer the important things to other repositories, easy to check whether you have the same thing at your repository, hence easy to decide that the wrongly designed Git repository was fully replaced elsewhere and can be thrown away.
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareAuthor Commented:
Thanks for your detailed explanation. I'm using Mercurial instead of Git, although I did so simply because BitBucket defaulted to Mercurial. I'm reading up more on the details and differences between the two so that I can make a better decision. I'm not far enough into the project(s) to make any difference if I have to start over with Git instead of Mercurial, so any thoughts on the differences would be welcomed as well.

Sorry, I know this is somewhat vague and all over the place, but I'm still in the "feeling the walls in the dark, looking for the light switch" stage with my knowledge of version control and such.
For the Mercurial vs. Git, they are the same in principle. I am a big fan of Python (the implementation language of Mercurial). Anyway, Git is probably more widely used, and it may be the reason to choose Git instead of Mercurial. For me, this is more important than the implementation language. It is clear that the tool used by more people need not necessarily be better than the other. On the other hand, the tool that is used more intensively may be developed to something more enhanced and matured than the other tool. So, the question is related to what will be used in future.

I did use Mercurial only passively, so I cannot compare.

Have a look at
"Mercurial vs Git: Why Mercurial?" ( , February 2012), and
"Git vs Mercurial: Why Git?" ( , March 2012) by the same author.
Scott McDaniel (Microsoft Access MVP - EE MVE )Infotrakker SoftwareAuthor Commented:
Sorry for my delay in closing this. I've been buried with projects.

I did learn quite a bit about versioning, and the best way to use the various tools. I've awarded points to most of your comments, as they have definitely helped me to better understand and use those tools.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.