Vermeiden von Zusammenführungskonflikten beim Zusammenführen des Masters in die angepasste Verzweigung pro Host
Ich möchte alle meine dotfiles in git repository mit separater Verzweigung speichern
für jede Maschine. Ich habe ein Problem, das ich nicht lösen kann, das mich blockiert
Verwenden von git für diesen Zweck. Ich würde gerne wissen, wie andere Leute
löste es.
Ich werde einen einzigen Zweig master haben, der nur enthält
Template-Definitionen und Definitionen, die allgemein sein sollen
für alle Zweige, zum Beispiel:
Ich werde @EMAIL@ durch meine korrekte E-Mail in den Maschinenzweigen ersetzen
und commit es aber SURFRAW_google_results wird gleich bleiben. Zum
Beispiel, auf work Zweig Ich werde das haben:
Jetzt habe ich beschlossen, SURFRAW_google_results=1000 auf 10 zu ändern
soll global geteilt werden, also ändere ich es zuerst in master :
und dann ich Rebase work auf master :
Und jetzt bekomme ich einen Konflikt, weil die Linie über der Linie I liegt geändert ist anders:
%Vor% Im Falle von bash könnte ich schnell davonkommen
einschließlich eines maschinenspezifischen Teils durch Sourcing-Mechanismus, aber wie wäre es
configs, die das Einbinden anderer Konfigurationen wie .fluxbox/keys oder .screenrc ?
1 Antwort
Statt gleichzeitig vorhandene Daten direkt zwischen Zweigen zu ändern (was zu einem Konflikt führt, wie in dieser Antwort dargestellt), können Sie darüber nachdenken Inhaltsfiltertreiber , mit .gitattributes Deklaration .
(Bild von " Git - Git-Attribute anpassen ", von" Pro Git Buch ")
Die Idee ist, diese dotfiles in der Version zu verwalten, aber mit Platzhaltern template anstelle der tatsächlichen Werte (abhängig von der Verzweigung).
Die generierten tatsächlichen dotfiles bleiben ignoriert (von .gitignore ).
Das bedeutet, dass Ihr tatsächlicher Arbeitsbaum nicht "schmutzig" wird.
Die Dateien mit den tatsächlichen Werten können auch versioniert werden, aber mit unterschiedlichen Namen (also keine Konflikte beim Zusammenführen / Umbasieren)
Das Smudgeskript wählt abhängig vom Namen der Verzweigung die richtige Wertdatei aus und generiert die richtige Punktdatei basierend auf der Vorlage für die Punktdatei, auf die das Smudgeskript während einer git checkout angewendet wird.
Um einen Schmierfleck zu haben, der sich je Zweig anders verhält, würde ich empfehlen, ein Skript aufzurufen, das mit dem Namen des aktuellen Zweigs beginnt.
Siehe ein Beispiel in meiner älteren Antwort " Bewährtes Verfahren - Git + Build-Automatisierung - Konfigs separat verwalten ".
Das OP erwähnt, dass das Entfernen des Indexes erforderlich ist, damit das Smudgeskript beim Auschecken angewendet wird. Das stimmt, wie ich hier erklärt habe :
Der Index ist der Mittelmann, um Dinge von Ihrem Arbeitsbaum in den Objektspeicher zu verschieben UND Dinge vom Objektspeicher in Ihren Arbeitsbaum zu verschieben.
Indem Sie den Index entfernen, zwingen Sie git, ihn wiederherzustellen, was bedeutet, dass Sie einen beliebigen Inhaltsfiltertreiber anwenden müssen, falls vorhanden.
Siehe " git: Dateien nach dem Erstellen eines Wischfilters erneut prüfen ".