0

I have been using SVN for a long time and now I am moving to git just to be "in fashion".

My trouble is how git project managers/software developers manage the versions of a program: not from the code's perspective, but instead from the customer's perspective.

I have a few projects that each belong to a customer. Each customer under a separate folder has a "projects" folder and possibly a "support" folder. The code of the project exists under each "projects" folder. Under "support" is some supportive documentation/scripts etc.

There is also the case where some clients share a product. Each of those are versions in terms of code or configuration. But it is of the same product.

Now, just trying to do that on the hard disk, I am stuck in that I have the .git under each project. Not under a customer folder. I don't like it, as I guess that this means I need to have a wiki (or a text file?) to remember(!) where the git repositories belong (for example, if a laptop goes busted... and I need to get all the git repositories. I have to have somehow get the repositories back on the disk).

On the other hand would it be better to have the git repository under the customer folder? But in that case, if I need to do "stash/branch/merge" would this "harm" the rest of the projects under the same "customer-umbrella-git" directory?

I can not imagine what would be stashed/merged/branched if one customer needs feature X for product Y and at the same time I need to fix a bug for project B. Having the git repositories under the customer's folder scares me.

Or is there a way to put a git property perhaps somewhere and eclipse/idea/windows explorer ( yeah sure...) would read this and give me a quick acknowledgement of what projects I have under what customer?

How do you manage this?

Improve this question
2
  • Question - when customers share a product, are all code changes eventually provided to both customers, or do some remain customer-specific?
    – Sarov
    Jul 3, 2018 at 17:31
  • You can't have for sure what will happen. There are projects that the code is 99% same. But there is variation. I believe all we face this obscurity.
    – hephestos
    Jul 3, 2018 at 18:46

2 Answers 2

Reset to default
1

I'm not sure where you got the idea that "git project managers/software developers manage the versions of a program [...] from the customer's perspective". I use git and I certainly don't have a separate repo for each customer...

Anyway, the following works well for my Team:

For products that have variations, but will eventually be merged

Use git's branching system for this; have a separate branch for each. One approach to this is to use the following branching system:

  • One master branch that represents the single 'Live' version of the code
  • One Beta branch per customer. Once a feature has been approved by that customer, it is merged into the master branch and other Beta branches are rebased onto master to obtain the change.
  • One feature branch per feature. Once the feature is ready for Beta, it it merged into the correct Beta branch(es).

For different products that are similar but will never be merged

Have three repositories. One for customer/product A. One for customer/product B. And one submodule/subtree (Disclaimer: I've never used subtrees) for the shared code.

This way, the two "variations on the same product" are actually treated as separate products/repositories entirely; they just share code between them.

For products used only by a single customer

Straightforward. One product, one customer, one repo.

In this way, every product always has one and only one non-submodule repository.

Improve this answer
3
  • Very interesting the whole idea. For the first bullet you always deliver master branch to each customer? Don;t you have the case that a branch is stable and good for customer-A but you can't deliver to customer-B the same code? For example end-of-contract. Or other legal obstacle. Or you can't because of technology gap. Lack of..server let's say... So you need to maintain a Branch (new updated code ) and master(for clients that do not get upgrade). Or you would split the Branch to another new entirely new master git ?
    – hephestos
    Jul 3, 2018 at 20:03
  • @hephestos How you use the branching system will be organization-specific. Do whatever makes the most sense for you. One approach may be to have another layer of indirection; master branch for totally-finished code, customer-specific 'Live' branches, customer-specific 'Beta' branches, and then feature branches. Just as a general guideline: when it's one product use branching, when it's multiple products use separate repos.
    – Sarov
    Jul 3, 2018 at 20:19
  • I will consider your approach and try to test this on "pet" projects. And I will need to have something like a "map" to know directly what project belongs to who customer and perhaps other dependencies... Thanks for your time.
    – hephestos
    Jul 6, 2018 at 16:52
0

I think, you should change your vision. It is not customer having versions and branches, but product does. Especially, if some products are shared across customers. So, you should have your ".git" folders under product folders.

If you need to have different product configurations for customers, then create "configurations" folder under your product folder.

In such case you will be able to add new features to product and to configurations, and fix bugs in parallel.

There is also Git Flow versioning design model which can be helpful for you.

Improve this answer
1
  • Thanks for the response Anton, yes truly this is an option. To adapt myself to the machine. But I really do not want to do that first. Second I wonder if other people think or have thought about it and what other solutions might take place. When I am working "solo" , providing the features, the code, the fixes, the patches, and I have also to maintain what I have given to whom, to remember dates or versions. Then becomes a luxury to have in my mind the "by-product" version control only. So I wonder if there is a "by-the-book" good way to truck "smartly" if I can say.
    – hephestos
    Jul 3, 2018 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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