So lösen Sie falsche Abhängigkeiten in Gerrit

Es scheint, dass bei der Verwendung von Gerrit standardmäßig alle Änderungen von der vorherigen abhängen. Ich verzweige nicht für neue Änderungen, ich arbeite einfach vom Master-Zweig ab und schiebe dann die festgeschriebenen Änderungen an einen entfernten Ursprung/Master. Eine Abhängigkeit wird jedes Mal erstellt, auch wenn die beiden Commits nichts miteinander zu tun haben.So lösen Sie falsche Abhängigkeiten in Gerrit

Ich bin auf einige Probleme gestoßen, die mich denken lassen, dass ich Git nicht richtig in Kombination mit Gerrit verwende.

Was soll in meinem git/gerrit-Workflow anders passieren, damit jeder Commit nicht vom vorherigen Commit abhängig ist? Ich habe auch versucht, eine Niederlassung für den Wechsel zu schaffen:

> git pull origin master 
> git checkout -b new_branch 
> #make a change 
> git add -A 
> git commit #with gerrit's commit hook in .git/hooks 
> git push origin <sha1>:refs/for/master

Dies funktioniert, aber gerrit berichtet immer noch eine Abhängigkeit von den zuvor begangen Artikeln.

Quelle

2012-05-01 Shellum

Ich bin nicht einmal sicher, was Sie fragen. Was meinst du mit "Abhängigkeit?" – ebneter

Gerrit zeigt, welche Probleme von einer Abhängigkeit abhängig sind. Zum Beispiel überprüfe ich in der Ausgabe # 1 auf Gerrit und checke dann eine völlig andere # 2 ein, die nicht einmal die selbe Datei berührt. Gerrit berichtet, dass # 2 von # 1 abhängig ist. Das scheint falsch zu sein. – Shellum

mit einem Git-Rebase -i und Entfernen der Abhängigkeiten selbst kann auch eine Möglichkeit sein, Abhängigkeiten loszuwerden. – cafebabe1991

Dies ist, was Gerrit bedeutet durch Abhängigkeiten - Ein Commit, das auf einem anderen Commit ist. Wenn beide in Überprüfung sind, hängt der neuere von dem älteren ab.

Wenn Sie nicht möchten, dass sie voneinander abhängig sind, erstellen Sie die Commits nicht übereinander. Erstellen Sie einen Commit, und erstellen Sie dann einen neuen Zweig basierend auf dem Master für Ihren nächsten Commit

(git checkout origin/master -b NEW_BRANCH_NAME).

Wenn Sie das zweite Commit zur Überprüfung drücken, wird es bereits veröffentlicht und es hängt nicht von irgendetwas ab.

Quelle

2012-05-01 21:36:11 Brad

Ich habe erwähnt, Verzweigung für jeden Code ändern ... aber wie in meiner Frage bearbeitet, scheint dies immer noch die gleichen Ergebnisse zu produzieren. Noch mehr Ideen? – Shellum

Der Befehl, den Sie verwenden, um einen Zweig zu erstellen (git checkout -b new_branch), macht den neuen Zweig oberhalb des aktuellen Commits. Sie möchten auf das zurücksetzen, was der Server als aktuelles Commit ansieht. Geben Sie dies im checkout-Befehl an.git checkout * Herkunft/Master * -b new_branch. – Brad

@Brad Ihr Kommentar macht Sinn. Ich wollte nur darauf hinweisen, dass die Dokumentation für git-checkout als letzten Parameter den Startpunkt hat: git checkout [-q] [-f] [-m] [[-b | -B | --orphan] ] [] So Ihr Beispiel wäre: git checkout -b new_branch _origin/master_ – Plazgoth

Ich habe gelernt, dies zu umgehen, indem Sie git reset --hard HEAD~1 nach jeder git push tun.

Quelle

2012-06-07 09:04:02 Mitch

Möchten Sie etwas dazu sagen, warum Sie das für falsch halten, vielleicht vermeiden, Fehlinformationen zu verbreiten und mich besser zu informieren? – Mitch

Das Problem mit diesem Ansatz, dass Sie das Commit vollständig loswerden, nachdem Sie drücken. Angenommen, Sie haben iterative Überprüfungen auf dem Gerrit, Sie möchten vielleicht das vorherige Commit basierend auf den Kommentaren ändern. Dieser Ansatz würde erfordern, dass Sie die Änderung erneut von Gerrit auswählen, um daran arbeiten zu können. Ich finde das schwierig in Fällen, in denen ich verzweifle, um eine große Reparatur zu tun und Setup auf diesen Code ausgeführt wird. Wenn ich eine kleine unabhängige Korrektur auf die gleiche Codezeile anwenden möchte, möchte ich nicht das Haupt-Commit für diese kleine Korrektur verlieren, da dies möglicherweise mehr Änderungen auf der Grundlage von Reviews auslöst. –

Kein Problem. Alle Commits, die übertragen wurden, werden auf dem Server und lokal gespeichert. Du arbeitest an einem, drückst es, dann arbeitest du an einem anderen. Wenn Sie Feedback zu einem erhalten und es erneut ändern möchten, überprüfen Sie es einfach, um daran zu arbeiten. Einen Zweignamen darauf zu setzen, ist eine Annehmlichkeit, nicht mehr. – clacke

Als Variante zu git reset --hard HEAD~1 Ich benutze diese stattdessen:

git reset --hard origin/master

Angenommen, ich arbeite in master für einen schnellen Wechsel.

Andernfalls ist die Arbeit in einem Zweig Zweig viel bevorzugt.

Es gibt viele Git Skripte zu verwalten Zweige Thema zu helfen:

git-flow
git extras
git create-branch

Ich bin sicher, dass es andere gibt.

Quelle

2013-03-13 14:25:57

Ich denke "git reset - harter Ursprung/Master" ist besser ... weil oben Befehl gab Fehler und arbeitete nach Platz in - und schwer –

So lösen Sie falsche Abhängigkeiten in Gerrit

Antwort

Verwandte Themen