Saving git from having to commit changes

Question

We have several configuration files in the project that 3 people are working on. However, these configuration files contain several lines that differ for each of us, so they cannot be changed or overwritten with commits. However, Git will not allow us to pull changes from other people unless we commit these changes to the configuration file, which means that it will again change the configuration of other members.

Being new to Git, it seems to us that we need to create branches and merge them into each commit to update our code - or use .gitignore. What is the right way to deal with this situation? We all need ongoing access to the changes that other members are making.

Answer 1

Tracking an example configuration file is usually a good approach. Then you may have an unconventional local copy. You can use githooks to help you apply the differences. You can have post-merge and post-check (and possibly even post-fix), track tracked to raw and, possibly, apply changes to create your individual version. How exactly you make the last bit is up to you - this is a script. A few calls to sed -i can do this, though.

Another possibility, if you can use two configuration files, or if the configuration files have some kind of "include" directive, is to have one traceable and one not trackable.

Answer 2

Do not check the configuration file.

If necessary, you can have config.example, which each of you copies to an unprocessed configuration file - this is how most projects handle this.

Answer 3

I found the value of using reasonable defaults in the application along with an additional configuration file that is ignored by version control. An example configuration file may be specified, but with a different name; usually "config.example.yml" (or any extension makes sense to you).

Answer 4

I am sure I recommend using the following technique, but ...

You can use filter drivers to customize the configuration file for each developer accordingly. A verified file may contain a common value, and each developer will have a smudge rule that will change it for them.

For example, if a line in a file called "config-file" that you want to change based on each developer looks like this:

 config: default

Then the developer will have this in his local .git / info / attributes:

 config-file filter = modify-config

and something like this in .git / config:

 [filter "modify-config"]
     smudge = sed -e 's / ^ config:. * / config: developers value /'
     clean = sed -e '/^config/s/.*/config: default /'

Answer 5

You can also use the serious git-fu, known as "rebase -onto", as described here .

Since I understand this approach, you have your own configuration changes in one commit on your own branch. Work in your branch. Each so often, you delete a branch above your configuration commit and stitch it onto the master. Repeat as necessary.

A good diagram of this in parenthesis is Chacon's upcoming Pro Git .

I think this is one of those things with Git that is best sorted out once. Use git config --global alias.lop 'rebase --onto etc. etc.' git config --global alias.lop 'rebase --onto etc. etc.' so you can just type, for example. git lop in the future.