2017-01-10 3 views
0

Sagen wir, ich habe einen Ursprung namens Myorigin und einen Klon namens Myklon. Ich möchte myclone mit myorigin Änderungen aktualisiert halten. In myorigin habe ich eine Datei, den Inhalt ist:Ist es möglich, git anweisen, bestimmte Zeilen zu ignorieren, wenn Sie Merge oder Rebase durchführen?

Name: myorigin 
some text 
some more text 

und nach dem Klonen dieser Datei in myclone I wie folgt ändern:

Name: myclone 
some text 
some more text 

Wenn in myclone tun I:

git fetch 
git merge origin 

es wird mir sagen, dass es Konflikte gibt.

Gibt es eine Möglichkeit, git bestimmte Zeilen zu ignorieren?

Sollte ich es anders angehen?

+0

Ein Konflikt ist eine Situation, in der Änderungen an den verbundenen Zweigen nicht sicher kombiniert werden können, normalerweise weil sie die gleiche Zeile (n) ändern oder widersprüchlich sind. Der menschliche Eingriff ist erforderlich, um den Konflikt zu lösen. Der Mensch kann entscheiden, eine der zwei Versionen zu behalten und die andere zu verwerfen oder die Änderungen von beiden Zweigen manuell zu kombinieren. – axiac

+0

@axiac Danke. Aber ich würde jedes Mal, wenn ich fusioniere, eine der beiden Versionen manuell akzeptieren müssen. Ich fragte mich, ob es einen Weg gab, es irgendwie zu machen. funktioniert für js Kommentare oder einen anderen Ansatz. – Alvaro

+0

Wenn bei jeder Zusammenführung Konflikte auftreten, liegt das Problem anderswo. Vielleicht sollte die Datei überhaupt nicht in das Repository gestellt werden. Ist es eine Konfigurationsdatei oder warum bekommen Sie Konflikte bei jeder Zusammenführung? – axiac

Antwort

3

Sie können eigene Merge-Treiber schreiben oder eine Reihe von Clean- und Smudge-Filtern schreiben, sodass Git diese Zusammenführung nicht durchführt oder diese Zeile nicht anzeigt. Aber im Allgemeinen, nein, es gibt keinen einfachen Weg, das zu tun, was Sie vorschlagen.

Als allgemeine Regel sollte jede Art von "Konfigurationsdaten" nicht an das Quell-Repository selbst übergeben werden. Wenn es angemessen ist, sollte das Quellenrepository stattdessen eine Beispiel-Konfiguration enthalten, und die tatsächliche Konfiguration wird woanders gespeichert (entweder .gitignore -d oder vollständig außerhalb des Arbeitsbaums).

Wenn Konfigurationen aktualisiert werden müssen, wenn der Benutzer von "FooBarix Version 1.3" zu "FooBarix Version 2.0" wechselt, sollte die Version 2.0 wahrscheinlich ein Konfigurationsmigrationsprogramm enthalten, das während des Upgrades ausgeführt wird und die ursprüngliche Konfiguration speichert Wechsel zu einer neuen Konfiguration (keine davon wird von Source als Teil von FooBarix selbst gesteuert). Dies bietet auch die Möglichkeit, die Konfiguration herunterzustufen, sollte es sich als notwendig erweisen, von 2.0 zurück zu 1.3.

Verwandte Themen