1

I'm freelancer who code for my customers. I have my own code base (code which I reuse in projects) which I developed throughout the times. I use git for code version control.

My own code base consists of several git repositories (.NET libraries, C++ libraries, etc.)

When I setup a new project for a customer I create new git repository for it and I add libraries from my code base as a git submodules to the project repository.

It works for me, but a problem arises when I have to share my code with customer. I would like to simply send him the git repository of the project, but I don't want to share with him my whole code base (e.g. all my .NET libraries which are included as a git submodule in the project repository). Only code really used in the project should be shared.

I can think of dividing my code base to smaller parts (not one git repository containing all my .NET libraries, divide it to smaller chunks). However I'm not sure it's really a solution.

Martin Dusek
  • 1,170
  • 3
  • 16
  • 41
  • I don't think your question has much to do with Git. In fact, you could be using any other version control system and you'd still have the same problem: how to _share common code across projects_. Have you considered packaging your libraries as NuGet packages and distribute them as binaries instead? – Enrico Campidoglio Sep 24 '15 at 11:32
  • I considered that but mainly my customer wants the source code, even for files from my code base. Of course, I don't want to provide him my whole code base, only files really used by the project. This is the problem I would like to solve. – Martin Dusek Sep 25 '15 at 10:41

1 Answers1

1

One way to do this would be (starting from project creation):

  1. Clone the original code base and set it as upstream.
  2. Create a new branch in cloned repo. Remove local 'master' branch. I.e. the one that is the main for the submodule.
  3. Truncate everything that is redundant for current project in new branch. You'll have to plan the repository structure beforehand and very well to avoid cumbersome and tedious selecting of required libraries/modules. How to clean up git commit history. How to cherry-pick added modules/libs from the child repo to main.
  4. Work.
  5. Send the code to the customer. Upstream project for the customer should be the one you work from, not the main master submodule.
  6. When everything is done - fetch main branch into cloned (child) repo and cherry-pick things that should be added to your code base or even better - merge them to main submodule repo in a batch.
  7. Remove / archive the support(upstream) for grandchild repo (your clients) when maintenance/support/lifecycle is done.

Don't know if there is a more straightforward way for achieving this, but if there is any way to set fetch permissions for branches - it would be perfect.

Another and actually a better way to setup your WoW would be to use gerrit. It has a support to setup access for specific branches and allows for a good integration process. Much better than GIT only.

Community
  • 1
  • 1
Zloj
  • 2,235
  • 2
  • 18
  • 28
  • Branching seems to be able to help with the issue. I have some notes/questions: Point 3) How will one perform truncating so my customer, once I provide him the project, won't be able to access my whole codebase through commit history? Point 6) Merging original code base back to the project's code base mean that in the next iteration of my project I will again need to truncate unneccessary files before sending the project to my customer. Point 7) What is grandchild repo? – Martin Dusek Sep 24 '15 at 08:50
  • @MartinDusek I've edited the answer, see updates. As for point 6 - you don't need to remove the child repo when sending it to customer. Well unless you just don't have where to store all this. Remember that you can for example create branches in main repository called 'project 1' 'project 2' etc. to reflect the current state of the project. In my suggested WoW you may as well keep the child repo forever or at least until the lifecycle of the project is over. Branches in main repo in this case would greatly reflect the states and stages of the particular project. – Zloj Sep 24 '15 at 09:08
  • @MartinDusek also, see my update regarding gerrit. Might be better than GIT-only. – Zloj Sep 24 '15 at 09:17
  • Thanks Zloj. I studied Gerrit a little. What would the point of access control be? Would it be: When I'm ready to share my code with the customer I branch to new branch, truncate everything redundant I don't want to share with my customer and add privilege to access the new branch to customer? I can't see that much beneficial for me. – Martin Dusek Sep 25 '15 at 10:44
  • @MartinDusek yes, that looks messy. I'm out of ideas, maybe someone else can help? Or maybe GIT just isn't suitable for this task? The main goal of git is to provide an exhaustive development history so it is designed to keep that history safe rather than providing an easy way to destroy it or alter it. Then again - you can make some deploy scripts to deploy the code for customer without GIT repo. Not sure if this is acceptable at all. – Zloj Sep 25 '15 at 11:15
  • It seems I have to change the workflow as current tools doesn't support my current workflow. Or prioritize what I need most. – Martin Dusek Sep 25 '15 at 11:59