2016-11-15 11 views
0

Ich bemerke oft das Problem von Konflikten, wo einige Zeilen nach dem ersten Commit (und Push) geändert wurden. Kann mir jemand sagen, warum und wie man das vermeidet?Git Konflikte beim Fixieren einer einzelnen Zeile

Ich verpflichte und schieben Sie eine neue Funktion

git commit -am 'my new feature' 
git push origin development 

Dann bemerke ich einen kleinen Fehler (eine Zeile)

git commit -am 'Bugfix' 

Aber git sagt, dass ich vor dem Push-Pull soll.

Ergebnis: ein Konflikt in der Zeile, die ich nach dem ersten Commit geändert habe. Das passiert sehr oft. Und es sollte ohne Konflikte funktionieren, da meine neuere Änderung vor der älteren Änderung bevorzugt werden sollte.

Nein, es ist nicht, weil jemand anderes die gleiche Datei festgeschrieben hat. Der Feature-Zweig wird von mir gepflegt. Wir benutzen Github.

Eine andere Sache ist: nach der Auflösung des Konflikts, NetBeans hat mich gezwungen, eine leere Festschreibung zu tun. Es hat keine Dateien gefunden, die geändert wurden, aber es hieß, dass ich mich verpflichten muss, zu beenden.

Die erste Version der Linie:

$duedate = $dateObject->format('%d.%m.%Y'); 

Und die feste Version

$duedate = $dateObject->format('d.m.Y'); 

Vielleicht hat es etwas mit einem Fütterungsmaterial zu tun, die nicht ordnungsgemäß beendet wurde?

Bearbeiten: Wir beobachteten dieses Verhalten, wenn es eine kurze Zeit (eine Minute max) zwischen den zwei Stößen ist. Vielleicht liegt es an asynchronen Uhren oder Github-Caches?

+2

Sie müssen sich irren. Jemand anderes hat es geändert. Wenn die Remote-Zweigstelle und Ihre lokale Zweigstelle identisch sind, können Sie ** keinen Konflikt bekommen. Versuchen Sie folgendes: 'git log -1 dev' und' git fetch && git log -1 origin/dev'. Sind die Sha-1 gleich? Wenn sie nicht sind, hat eine andere Person den Zweig gewechselt. – Alderath

+1

Welchen genauen Konflikt bekommen Sie? Hat es mit Zeilenenden zu tun? – Jubobs

+0

Sie sind gleich! Ich habe Informationen zum obigen Konflikt hinzugefügt. – Corni

Antwort

0

Wir haben die Antwort gefunden. Dies geschieht, wenn ein Commit für einen anderen Commit geändert wird, der bereits in das Repository übertragen wurde. Sie sollten nur ändern verwenden, wenn das Commit nur in Ihrem lokalen Repository ist.Ich weiß nicht, warum Git-Kunden hier warnen, aber in fast allen Fällen macht es Ärger.

0

Es bedeutet, dass jemand anders den gleichen Zweig geschoben hat, nachdem Sie ihn gedrückt haben. GIT ist ein Kollaborationswerkzeug, daher sollten Sie solche Anwendungsfälle sehr oft erwarten.

+0

Ich fragte meinen Kollegen. Er hat sich nicht verpflichtet. Dieser Feature-Zweig wird nur von mir gepflegt. – Corni

+1

Es ist einfach zu sehen, was passiert ist, wenn Sie git log ausführen oder den Verlauf der Verzweigung in der Serveroberfläche sehen (welcher Server benutzen Sie?) – yorammi

0

git push && git pull ist idempotent, wenn niemand sonst irgendetwas drückt.

Daher sollte git push && git -am 'my commit && git pull nie zu einem Zusammenführungskonflikt führen. Sie haben alle die gleichen Objekte, die der Remote-Server hat, also sollte der Git-Pull nichts Neues einführen.

Daher: Jemand fügt neue Commits hinzu oder ändert Ihre Commits.

Sie behaupten, dass Ihr Kollege diesen Zweig nicht vorantreibt. Ich vermute also eine Art von Automatisierung. Verwenden Sie serverseitige Hooks?

weitere Informationen zu erhalten, tun:

git commit -am "whatever" 
git log -1 
git push origin development 
<change something? 
git commit -am "more whatever" 
git pull 
git log -3 

und teilen Sie uns die Ausgabe von beiden Protokollbefehle

+0

Wir verwenden hooks aber auf unseren Servern, nicht auf github. Server sind so konfiguriert, dass sie als Push-to-deploy und als anderes Repository (nicht als "Ursprung") hinzugefügt werden. – Corni

+0

Es ist schwierig, die Protokolle anzuzeigen, da es jetzt andere Commits gibt. Ist es möglich, dass schlechte Taktsynchronisation der Grund ist? Oder schiebt Github Cache (wegen der Last)? – Corni

+0

Ist dieses Problem wiederholbar? Oder ist es einmal passiert? Ich habe das Gefühl von der OP, dass es regelmäßig passiert. Also, wenn Sie es mit der oben genannten Technik wiederholen können, sollten die Protokolle nur Ihre 'Test' Commits anzeigen. (Es sei denn, Ihre Kollegen hämmern alle rechts und links fest - in diesem Fall bitten Sie sie, 10 Minuten lang zu drücken.: P) – Pod

Verwandte Themen