Mehrere Teilmengen von Punktdateien verwalten

416
GameKyuubi

Ich verwende git zum Speichern meiner Dotfiles, aber jetzt, da ich mit der Implementierung mehrerer Linux-Implementierungen begonnen habe, stelle ich fest, dass meine Dotfiles zwischen den Geschmacksrichtungen etwas voneinander abweichen, je nachdem, wofür ich das Build verwende und wie es funktioniert Geschmack wirkt. Wie können verschiedene Dotfiles für verschiedene Geschmacksrichtungen nachverfolgt und gespeichert werden? Kann ich dasselbe Repo verwenden oder sollte ich andere verwenden, auch wenn viel Code gemeinsam genutzt wird? Zum Beispiel möchte ich separate Sets von Punktdateien für mein Arch-Mediencenter, WSL-Ubuntu und meine tatsächliche Ubuntu-Partition verwenden. Es gibt Gemeinsamkeiten, die ich gerne teilen möchte, und Unterschiede, die ich gerne getrennt halten möchte. Wie würdest du damit umgehen?

1

1 Antwort auf die Frage

0
Stefan Moch

Repositories

If you count the git working dir repositories where you check out your dotfiles, you will have more than one anyway. But you do not need multiple git repositories for integration – one is enough in this case. (If you have access to the other home directories, you do not even need this, but a single bare repo which you can access from all checkouts is usually the easiest way.)

Strategies

Basically you can work in one branch and differentiate between the environments without the help of git and use git only to track and share the changes. Or you keep the deviant changes in branches. Details:

1 Branch

You work on one branch and keep it up to date in all enviroments. For the differences you use other mechanisms, e.g.

  • for dotfiles which are actually scripts, ifs depending on the environment can do things which are run in one environment and not in the others
  • dotfiles in a git directory are usually linked with symlinks to their right places in the home directory: set it up so that the right files get linked if there are multiple variants
  • generating the files from a single source via a preprocessor may also be an option, especially if there are ongoing changes from different environments and changes for all environments in the same file(s)

n Branches

Have a main branch (master) were changes go regularly. Each environment has its own branch which should reflect the files for this environment. The main branch may be one of the environments, if that is were you usually work and the other environments are the same + modifications. The main branch may also be independent, but if every environment differs from it, how do you test the content of the main branch?

Changes specific to an environment (i.e. where they differ from your main branch) can be committed into the branch of this environment. Keeping up to date with the main branch then means, you git merge the changes from the main branch into all your environment branches. You do not git merge them back into the main branch, because that would bring the differences into the main branch. (If you made changes in an environment you want to have in the main branch – but not all of them – git cherry-pick lets you apply these changes separately.)

Which one to use

Have a look at your files and their differences to decide which way to go. The n branches strategy limits the need of additional tooling, but effectively you have n different versions and use git tooling to keep them in sync, but different. (This might be a case of “if all you have is a hammer, everything looks like a nail”.) The 1 branch strategy defines one source for your configuration and uses git only as distributed version control system, you may need additional scripts here for setup, preprocessing, etc..