Git zeigt alle Änderungen von allen in einer Branche, als ob meine eigenen Änderungen

Question

Ich bin kein Meister der Git so entschuldigen Sie mich, wenn ich auf etwas schrecklich falsch bin.

Ich bin in einem Team-Projekt und ich habe eine neue Zweig Z von Zweig X (die unsere Entwicklungszweig war) erstellt, machte meine Änderungen daran und es ist seit ungefähr einer Woche in meiner lokalen Niederlassung. Gleichzeitig hat sich unser Team entschieden, zu einer Methodik zu wechseln und die neue Niederlassung Y als Entwicklungszweig zu nutzen. Seitdem wurde jedes Commit von anderen Leuten (und mir, in anderen Aufgaben) in den Zweig Y übertragen. Heute wollte ich meine Änderungen in Zweig Z mit dem neuen Entwicklungszweig Y zusammenführen. Ich habe insgesamt etwa 15 Dateien geändert insgesamt. Wenn ich jedoch versuche, die Verzweigung git zusammenzuführen (wir sind in Visual Studio Online, wenn es einen Unterschied macht), habe ich einen Zusammenführungskonflikt von ungefähr 13 Dateien (einschließlich einiger Dateien, die ich nicht einmal mein ganzes Leben lang berührt habe). Ich habe in Visual Studio "Abbrechen" gesagt. Ging zur Verzweigung von Y, synchronisierte mit ihm (was holt, zieht und schiebt in der Reihenfolge, wenn erforderlich), ging zurück zu meinem Zweig Z, fusionierte Änderungen und versuchte erneut zu synchronisieren. Es sagte, dass ich auf dem Laufenden bin. Ich habe eine Pull-Anfrage geöffnet, um Z auf Y zu verschmelzen, und hier ist das Problem:

Git denkt, dass alle Commits/Änderungen von allen im Team in der letzten Woche als meine Änderungen vorgenommen. Die Pull-Anforderung enthält buchstäblich Hunderte von Änderungen, die von anderen Personen vorgenommen wurden, die sich bereits auf der Verzweigung Y befinden. Wie kann ich meine Pull-Anfrage nur meine Änderungen in der Verzweigung einschließen lassen, und warum Git sogar versucht, Änderungen auf Y zusammenzuführen, die bereits auf Zweig Y sind, zeige sie, als ob sie alle meine Änderungen sind (wenn es nicht ist) ?

Answer 1

Ich denke, während X in Z verschmelzen und dann versuchen, es in Y etwas falsch verstanden oder Pockets erwähnte in Ihrer git Geschichte gebrochen zu verschmelzen. Ich habe nicht die genaue Antwort, warum dies geschieht, aber was ich in diesem Fall folgen wird eine Niederlassung von dem Basiszweig und cherry-pick die Festschreibungen zu erstellen:

git checkout Y 
git fetch origin && git pull origin Y 
git checkout -b new_X 
git cherry-pick commit_hash 

Wenn Sie mehrere Commits dann cherry-pick die Commits haben in sequentieller Art wie das Cherry Picking, das Commit, das du zuerst begangen hast und so weiter.

Sie haben auch eine Option zu rebase der Zweig, aber manchmal Rebasieren verursacht eine Menge von Konflikten, wenn sie falsch oder in diesen Fällen durchgeführt werden. Dies ist nur meine persönliche Erfahrung von Konflikten während Rebasing Ich sage nicht, dass es immer kommen wird, also bevorzuge ich cherry-pick statt rebase in diesem Fall.

Answer 2

Es gibt eine wichtige Sache, die Sie sicher sein müssen, dass ist, ob ein Zweig namens Z in remote existiert (vielleicht von Ihnen geschoben oder von anderen erstellt).

Wenn Zweig Z in Remote-Repository vorhanden sind, hat es schwere Chancen, dass andere Zweig Z geändert. So enthält es nicht nur Ihre Änderungen, nachdem Sie aus der Ferne ziehen. Sie müssen also die Commit-Historien finden, die von Ihnen festgelegt wurden. Es gibt zwei Möglichkeiten, wie Sie die Änderungen des Zweiges Z wiedergeben kann Y verzweigen, wie unten (wir den Graphen verwenden können, um darzustellen):

   I---J Y 
      /  
A---B---C---H   X (development) 
    \ 
     D---E---F---G Z 

1. die Änderungen, die Sie gemacht erfahren. Angenommen, in Zweig Z wird der Commit von D bis F von Ihnen gemacht, also können Sie git checkout Z und git reset --hard HEAD~ verwenden, so dass HEAD auf Zweig Z auf F zeigt.

Sie die Änderungen wiedergeben können Y direkt verzweigen, verwenden git rebase --onto Y <commit id for B> Z, wird das Ergebnis als:

   I---J---D’---E’---F’ Y 
      /  
A---B---C---H       X (development) 

2. Um nicht die Änderungen anderer zu stören, Sie Sie können auch einen neuen Zweig erstellen und Ihre Änderungen darauf kopieren. Verwenden Sie diesen Befehl:

git checkout Z

git checkout <commit id for F>

git checkout -b newZ

und dann können Sie create a pull request to merge branch newZ into branch Y, diese Zusammenführung ist für die Änderungen.

Wenn Z-Zweig nur in Ihrem lokalen Repo existiert, so wird diese Datei tatsächlich von anderen Entwicklern in Y-Zweig geändert. Wie die Datei test.cs wurde nicht in Z-Zweig geändert, aber andere Entwickler modifizierten es in Y-Zweig. Wenn Sie Z in Y zusammenführen, wird in der Datei test.cs ein Konflikt angezeigt.