CODEWITHSUNDEEP
gitgithub
user1737794
user1737794

Reputation: 123

Github: looking for a smart Git setup with shared files

I'm fairly new to Github and would like some advice how to arrange my workflow.

We have a small web application that we run on Mac Mini's using XAMPP. We have several Mac Mini's throughout the country and I was looking for a good way to manage the software and update it, because I was getting really frustrated with all the different versions.

The thing is that some files of the software are shared, but some files are specific for each client/Mac Mini. I'm looking for a easy setup so I have to change the common files only once and still have specific files (like templates) for each client. The current situation is this:

I'm looking for the best way to manage this. I did some research on this topic, but I hope someone can advice me for this specific situation. I feel I have the following options:

  1. Put everything in 1 repo but with the specific files in separate branches (do I have to push the changes to the common files to each client branche after a update?)

  2. Use 2 repo's (and use .gitignore the separate the common files from the specific files). 1 with the common files and 1 with the client specific files (in separate branches). My early research told me that this isn't possible because everything is in my root and not a specific directory

  3. Use git-subtree

  4. Use git-submodules

  5. Use gitslave

  6. Anything else?

Ideal I'm looking for a solution that can be managed with a OSX Git GUI.

About my workflow. I hope that I can make all the changes to the code directly from my software folder in htdocs. If I only make changes to the common files I want to commit this to the common repo of course. If I make changes to a specific file I want to first connect to the right branche or repo and then update this. I'm sorry for the incorrect terminology, but I hope it is still clear enough.

Would be very nice if someone can point me in the right direction.

Upvotes: 2

Views: 215

Answers (1)

sleske
sleske

Reputation: 83577

As far as I can see, the only solution that would work inside git is option 1 (branches).

The others all will not work if the files to be treated differently are all in one folder.

do I have to push the changes to the common files to each client branche after a update?

Yes, you do. Actually, you'd need to first merge your changes into the client branches (to be precise, into your local copy of the client branches), then push out all the client branches. That should work, though it may be a bit awkward. You could mitigate this by automating with some scripting.

If you can put the customized files into subfolders, then yes, you could use git-submodule, git-subtree or similar. However, I don't think that would work well in your case. git-submodule et al. are meant for situations where you want to keep things in different repositories. This means that the two parts (repositories) can be cloned independently, versioned independently, tagged & branched independently etc.

However, as far as I understand this is not what you want. The customized templates are all part of the software product, and will evolve along with the rest of the system. So having them in separate repos will only cause trouble (e.g. if you branch, you would need to branch each submodule separately - and, even worse, merge each submodule separately).

You just want to maintain different "versions" of some files, and this is just what branches are for.

However, you should consider a different approach, namely performing the system-specific customizations at run-time.

How to do this depends on the specifics, but as an idea, you could have a table of system-specific things. Then you detect your host system on startup (get hostname or similar), and apply the customizations.

This avoids all the problems with multiple branches, synchronizing them, testing them all and making sure to deploy the right one. Also, maybe even more important, you get to work on one codebase, and you can exploit similarities between the systems. Finally, you can switch individual parts of the customization on and off at runtime, which greatly simplifies debugging problems related to the customizations.

In my experience, this is a simpler and more robust approach than deploying files, maybe even different code on different systems. I have used this idea on several projects myself and it worked well.

Upvotes: 1

Related Questions