CODEWITHSUNDEEP
git
Buddhika Ariyaratne
Buddhika Ariyaratne

Reputation: 2433

git for two applications with one different file

I have a very same application under development for two institutions. All the code is 100% similar except for the names in a single properties file. In future, improvements needed are also shared between these two. Is it possible to manage source code for both applications under one git repository, so that improvements and bug fixes will be very easy, but will have different properties files?

Upvotes: 4

Views: 103

Answers (4)

Samy Dindane
Samy Dindane

Reputation: 18716

If a single file only is concerned, I find it overkill to use a branch for each customer.

The way I would do it is ignoring the configuration file (let's call it conf.properties) and versionning a file called conf.properties-dist that contains the default configuration information.
The code you'll deploy will be the same, and you'll only need to cp conf.properties{-dist,} and edit conf.properties with the information about the institution. These steps are usually done once —after the first deployment— and stay untouched over time .

Upvotes: 2

moonwave99
moonwave99

Reputation: 22812

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

If the template changes, you just update the README.

Upvotes: 5

Tadeusz A. Kadłubowski
Tadeusz A. Kadłubowski

Reputation: 8363

Two sample ways to organize this two projects:

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

Even simpler solution: don't include the target properties file in the Git repository at all. Write a configuration tool that will parametrize the properties at deployment time.

Upvotes: 3

Lasse V. Karlsen
Lasse V. Karlsen

Reputation: 391486

Yes, use branches.

First commit everything that is common, including a common (possibly never going to be actually used) version of the file in question:

(1)

Then, create a branch and add the changes to that file:

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

Then update back to the original changeset, and create another branch with the other changes to that same file:

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

Then you develop from the (1) branch forward, merging into the respective (customer?) branches as you see fit:

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

etc.

Note that this can quickly become unwieldy if you have many customers, or many such smaller differences, there might be other ways to handle the differences, such as a build system that replaces a file as part of the build, instead of having N branches for such minor differences.

In other words, if the differences are related to things like branding and features that each customer have access to, a build system would prepare different distributables for each customer, already configured with the right files and configuration. This would need no extra branches at all (beyond what you should already have related to development, testing, production, etc.).

Upvotes: 6

Related Questions