Git Pull request bei verändertem Inhalt

#1

Hallöle,
ich hab nochmal eine Frage zu Git, mir ist eine elementare Sache immer noch nicht klar, die ich unbedingt klären möchte.
Bisher hab ich es nur für mich privat genutzt, um mir Sicherheitskopien anzulegen, d.h. ich habe immer nur in einem Zweig persönlich committet, wenn ich was neues gemacht habe und höchstens ggf. mal auf einen anderen Punkt zurückgesetzt. Hab es auch immer mit einem Remoteverzeichnis auf GitHub synchronisiert, habe aber auch nicht mehr als Push und Pull gedrückt.

Nun möchte ich mit anderen an einem Projekt arbeiten, das zentral auf GitHub gelagert wird und eine Sache ist mir immer noch schleierhaft.
Wie kann ich etwas committen, wenn sich inzwischen das Verzeichnis schon verändert hat, weil jemand anders was verändert hat?
Bisher haben sich da immer zwei verschiedene Situationen ergeben:
Entweder ich pulle vorher alles was sich verändert hat vom Remote-Verzeichnis und dabei hat er meine Änderungen verworfen.
Oder ich pushe meine Änderung gewaltsam hoch und überschreibe damit dann die Änderungen der anderen.
Damit hab ich ja nun nichts gewonnen.

Kann mir jemand erklären, wie ich etwas hochladen kann, ohne dabei meinen eigenen Kram oder den der anderen zu verwerfen? Ich bin mir dem immer noch nicht klar geworden. Zusätzlich will ich sagen, ich nutze das Programm SourceTree, also eine sehr komfortable Grafische Oberfläche anstatt der Konsole. Ich bin mir dem bewusst, dass das zum Lernen vielleicht dann das falsche ist, es nicht auf der Konsule zu machen, aber ich bitte darum, bei etwaigen Lösungsvorschlägen von euch mit Code eine Erklärung mit dabei zu haben. :slight_smile:

Vielen Dank!

Schöne Grüße

#2

pull verwirft deine Änderungen nicht, sondern merged sie.

Pull = fetch + merge

Suche doch mal nach pull, fetch, merge und rebase :wink:

Natürlich nur auf Feature branches und dann einen pull request auf Master :slight_smile:

hier noch was zum lesen: https://www.atlassian.com/git/tutorials/comparing-workflows/

#3

Der Mittelweg, den Du suchst, heißt “merge”.

[ol]
[li]Du committest Deine Änderungen in dein lokales Repository.
[/li][li]Du synchronisierst Dein lokales Repository per “fetch” mit dem zentralen Projekt-Repository
[/li][li]Du mergest den zentralen Zweig des Remote-Repository in deinen lokalen Stand. [/li]```
git merge origin/master


[li] Du pushst das gemergeten Stand in Dein-Remote-Repository und stellte im GitHub des Projekts einen Pull-request ein.
[/li][/ol]
Dabei werden Konflikte entstehen, wenn andere in den selben Dateien geändert gaben.

Solange sich die Änderungen der anderen auf andere Zeilen in einer Datei beziehen kann git das meist  selbst auflösen.

Falls andere die selben Zeilen einer Datei wie Du geändert haben ist die Wahrscheinlichkeit, das git selbst raus bekommt, wie diese Zeile am Ende aussehen muss deutlich geringer (aber nicht 0). Solche Konflikte bietet git dann zur händischen Nachbearbeitung an.

Tipp (auch wenn jetzt wohl schon zu spät): viele kleine Commits kann git besser mergen. Unittests helfen beim Check, ob das Gesamtergebnis  fachlich noch valide ist.

bye
TT
#4

Liest du: https://guides.github.com/introduction/flow/ !!!11elf

#5

Hallöle,
ich danke euch allen für eure hilfreichen Antworten. Ich konnte das Problem damit nun bezwingen. Die Doku zu Atlassian finde ich sehr knorke, sie gehört direkt zu SourceTree. Daher verwundert es mich, dass ich sie vorher nie wahrgenommen habe und auch beim Suchen nicht drauf gestoßen bin.

Danke schön und schönes Wochenende!