Git for two applications with one file

Question

I have the same application that is being developed for two institutions. All code is 100% similar, with the exception of names in a single property file. In the future, improvements are also needed for the two. Is it possible to manage the source code for both applications in the same git repository, so that fixing and fixing bugs will be very easy, but will have different properties files?

Answer 1

Yes, use branches.

First, pass everything that is shared, including the shared (possibly never used) version of the file:

(1) 

Then create a branch and add changes to this file:

  (2) <-- customer A / (1) 

Then go back to the original changeset and create another branch with other changes in the same file:

  (2) <-- customer A / (1) \ (3) <-- customer B 

Then you start from branch (1) forward, merging with the corresponding (customer?) Branches, as you wish:

  (2)---------(6) <-- customer A / / (1)---(4)---(5)---(8)---(9) <-- development trunk \ \ (3)---------(7) <-- customer B 

and etc.

Note that this can quickly become cumbersome if you have many clients or many of these smaller differences, there may be other ways to handle the differences, such as an assembly system that replaces the file as part of the assembly, instead of having N branches for such minor differences.

In other words, if the differences are related to such things as branding and features that every client has access to, the build system will prepare different distributions for each client that are already configured with the correct files and configuration. This will not require any additional branches (besides the fact that you should already have been involved in development, testing, production, etc.).

Answer 2

I would not put the configuration files under version control in this case - just indicate in README that a configuration file should be provided based on this example template, for example. database credentials.

If the template changes, you simply update the README.

Answer 3

Two examples of how to organize these two projects:

Have a branch for each project. Say master-a and master-b . Both follow the master symbol to the letter, only they have one additional lock each, which has a custom properties file for each project.

An even simpler solution: do not include the target properties file in the Git repository at all. Write a configuration tool that will parameterize properties during deployment.

Answer 4

If only one file is involved, I find it redundant to use a branch for each client.

The way I do this is to ignore the configuration file (let it call conf.properties) and the version of the conf.properties-dist file that contains the default configuration information.
The code you deploy will be the same and all you need to do is cp conf.properties{-dist,} and edit conf.properties with institution information. These steps are usually performed once - after the first deployment - and remain unchanged over time.