1

Firstly, I'm new to VSTS and Git, so apologies if my terminology gets muddled!

PROBLEM

My situation is that I have a VS/C# Project (called "PluginBase") that is, essentially, "starting template" code for a plugin. Historically, I've would just copy that PluginBase project code every time I wanted to create a new "tailored/derived" build for a particular customer.

What I would like to be able to do is, as and when bug fixes are resolved and features are added to the PluginBase project, I'd like the option to migrate these changes to one or more of the "tailored/derived" builds. Likewise, if the bug was first found while developing a "tailored/derived" build, I'd like to migrate that back to the PluginBase plugin.

IDEAS

From my research, I've come across a few "possible" ways of achieving my goal, but I'm not sure which (if any) of these approaches are suitable.

  • Branches
    • Seems the common approach, perhaps the "best", but...
    • Means all code must be in the same repository? (otherwise can't "cherry pick" across) - which I'd prefer to avoid as this may not always be possible
  • Git Submodules
    • Seems more intended when projects are sharing a common "library" (not deriving from same code-base)
    • Also not sure Visual Studio fully supports this feature
  • Cherry Pick
    • Doesn't seem possible to do this from one repository to another?
  • Git Patch
    • Doesn't seem Visual Studio supports this feature yet?

So, if anyone has any advice, guidance or new suggestions for approaches I could (or should) be using, I'd really appreciate your input.

Many thanks! :)

Paul Nicholas
  • 319
  • 3
  • 10
  • 2
    why do you want to avoid having all code in the same repository? – prof1990 Jan 11 '17 at 13:31
  • 1
    What @prof1990 said. I've had cases where I had tailored versions of the same code in different repositories, and it isn't nice. Life is so much simpler when they're branches of the same repository. – Jon Hanna Jan 11 '17 at 13:35
  • "branches of the same repository" isn't a thing in git. Perhaps you mean forks? – Joe Phillips Jan 11 '17 at 13:39
  • There is at least one more way. You can have more than one remote repository. Example: You have a base module 'SRC'; fork the repository to 'A' and download it. You can have in local copy of 'A' more than one source. After that add 'SRC' to 'A' as secondary repository. When you make a change to 'SRC', use "fetch all" in 'A'. Now you can merge any branch from 'SRC' merge to 'A'. In this case even cherry pick should work, but I did not test it. The only problem is, that you need to use a GIT server. – Julo Jan 11 '17 at 13:42
  • @prof1990 Thanks for your advice. The reason I wanted to avoid having all code in one place was so I could keep "customer-specific" code in one repository and have core code in another. But it's looking like I may have to reconsider that one. P.S. - I'd originally figured I'd just "Fork" (like Github) for each customer project off the base project and use Pull Requests to push commits back/forth. Then I realised that "Fork" is a GitHub feature, not currently present in VSTS. – Paul Nicholas Jan 11 '17 at 13:49
  • Fork is not much more than a clone http://stackoverflow.com/questions/6286571/are-git-forks-actually-git-clones, and a pull request is basically a request for a chery pick. It is possible to have multiple layers in git if securety is your main concern https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_distributed_git – prof1990 Jan 11 '17 at 13:58
  • I would have added Git subtree to the list – Giulio Vian Jan 11 '17 at 16:53

1 Answers1

0

Git Branches are definitely the way to go. The code indeed has to be in the same repository, git stores change sets and in order for a change set to be applied git has to know what happened since the code-paths split or it can not replace the correct lines of code.

Make a branch for each time you roll out a version to a customer, you can then cherry-pick across the different branches.

prof1990
  • 480
  • 3
  • 11
  • Seems pretty unanimous that this is the recommended approach (and the one to give less headaches!). Thank you all again for your advice! :) – Paul Nicholas Jan 11 '17 at 14:34