2017-12-30 27 views
1

Ich bin neu zu Git so ich verstehe das System nicht vollständig. Ich habe hier auf stackoverflow eine ganze Reihe von Artikeln und Erklärungen gelesen, und während ich glaube, dass sie meine Frage beantworten, verstehe ich diese Antworten nicht.Wie kann man Zweigstellen ohne Merge/Rebase auf dem neuesten Stand halten?

Ich möchte git verwenden, um einen Feature-Zweig zu haben, der nie in Master zusammengeführt wird, aber immer auf dem neuesten Stand gehalten wird mit Ausnahme der Hauptunterschiede (einige Dateien, die in der Initial Commit für den Zweig).

Im Wesentlichen, was ich glaube, die Lösung ist, Master in den Feature-Zweig zu verbinden, und dann den Kopf auf den vorherigen Master zurückgesetzt, aber ich nehme an, dass wird die Zusammenführung ungültig machen?

Es tut mir leid, wenn dies eine noob Frage ist, aber ich habe eine harte Zeit, meinen Kopf um diese ganze Sache zu wickeln.

+0

* „Ich habe gelesen, hier eine ganze Reihe von Artikeln und Erklärungen auf Stackoverflow“ * erforderlich erhalten - haben Sie das [Git Buch] lesen (https://git-scm.com/book/de/v2)? – axiac

+1

Was du beschreibst, nämlich einen Zweig zu halten, der niemals in "Master" verschmolzen wird, klingt auf lange Sicht nach einer schlechten Idee. Schließlich könnten die beiden Zweige bis zu dem Punkt divergieren, wo eine Zusammenführung mit "Master" unhaltbar wird. Warum denkst du, dass du einen solchen Zweig brauchst? –

+0

@TimBiegeleisen mein Anwendungsfall unterstützt eine DPI, die ich sonst nicht unterstützen kann (Anzeigegröße 'small' auf' xlarge', 'xxxhdpi' Gerät, was zu einer höheren DPI führt, die ich in Layouts einstellen kann, siehe meine vorherige Stapelaustauschfrage). Also, da ich nicht zulassen kann, dass Android das Layout für mich setzt, habe ich beschlossen, ein spezielles Layout zu erstellen und es in einem speziellen Zweig zu behalten, aber ich würde gerne alle grundlegenden Bugfixes zusammenführen, ohne das zu beeinflussen App, die nur für 99% der Geräte funktioniert, nur um meine eigenen zu unterstützen. – eydryan

Antwort

0

Ich verstehe nicht, Ihr Problem mit rebase Workflow

wenn ich Ihre Situation zu verstehen ist:

* [HEAD master origin/master] a commmit 
| 
* ... some history 

Sie eine Änderung in einer XML-Datei angelegt (in einem anderen Zweig hier modified genannt)

Wenn jemand den Remote-Master-Zweig aktualisiert, haben Sie (wenn Sie einen Befehl git holen Ursprung)

* [origin/master] last commmit 
| 
| * [HEAD modified] added or modified XML file 
|/ 
* [master] a commmit 
| 
* ... some history 

Lösung Ihrer MODIFIED BRANCHEN AKTUALISIERUNG

1) aktualisieren Sie Ihren lokalen Master-Version

git checkout master 
git pull origin 

und Sie

* [HEAD master origin/master] last commmit 
| 
| * [modified] added or modified XML file 
|/ 
* a commmit 
| 
* ... some history 

2) dann erhalten

git rebase master modified 

und Sie

* [HEAD modified] added or modified XML file 
| 
* [master origin/master] last commmit 
| 
* a commmit 
| 
* ... some history 

kein Reset

+0

Lesen Sie besser meine Lösung ... Master und Herkunft Master nie Ihre Änderung Aber modifizierte Version, die nur eine lokale Niederlassung ist nicht auf der Fernbedienung, wird mit Master –

+0

up to date sein Ich glaube nicht, Sie verstehen, ich Ich möchte diesen Zweig niemals zum Master machen oder diesen Zweig zum Master zusammenführen/neu erstellen, aber ich möchte ihn immer mit Änderungen im Master aktualisieren. Im Wesentlichen sieht mein Anwendungsfall wie folgt aus: https://i.imgur.com/Mj1lQOh.png – eydryan

+0

Ich will auch nicht nur nur lokal diesen modifizierte Zweig haben, ich will es auch auf GitHub existieren. – eydryan

Verwandte Themen