Git - Best Practice: Wie man sehr oft zwischen Zweigen wechselt und multiple Commits vermeidet?

Ich arbeite an einer Validierungssoftware. Ich halte den Master-Zweigcode, der immer bereit ist, Tests zu starten. Also entwickle ich die neuen Funktionen in anderen Branchen (dev für ex). Dies ist ein klassischer Git-Workflow.Git - Best Practice: Wie man sehr oft zwischen Zweigen wechselt und multiple Commits vermeidet?

Meine Sorge ist, dass es passiert, dass ich zwischen Meister und Entwickler 10 Mal am Tag wechseln muss, weil die Designer mich bitten, ihre Updates zu überprüfen.

Im Moment weiß ich nur einen Weg:

meine Arbeit an Entwickler mit der Meldung "Regression erforderlich" Commit
Switch to master-Zweig
Regression Run und geben Feedback
Wieder einschalten und weiterarbeiten

Das ist nervig b wegen der nutzlosen Geschichte, die auf dem Dev-Zweig erstellt wurde.

Gibt es eine andere einfache Art und Weise (ich bin ein Anfänger), die mehrfache commits auf dev Zweig zu vermeiden?

Vielen Dank für Ihre Hilfe!

Quelle

2012-04-12 Plouff

Wenn Sie nicht stash (was die richtige Lösung ist), oder wenn Sie aus Versehen committen, haben Sie zwei Optionen, entweder 'git reset HEAD ^' so dass das Commit nicht gezählt wird, und die Änderungen nicht sind verloren oder nach Beendigung der Arbeit, 'git commit --amend', so dass Sie diesen Commit addieren, ohne einen neuen zu erstellen, und Sie können auch die Commit-Nachricht ändern. – c00kiemon5ter

Am Anfang war es meine Idee. Versuchen Sie, das Commit _Regression erforderlich_ zu aktualisieren, wenn das nächste Feature für den Dev-Zweig bereit ist. Aber ich war mir sicher, dass es einen besseren Weg gab. Danke für die Commit-Tricks. Ich dachte "-" wäre nur für Text! Jetzt weiß ich ein bisschen mehr Kraft ... – Plouff

Vor dem Umschalten der Zweige, tun Sie git stash. Dadurch wird der aktuelle Status Ihrer Arbeit auf einfache Weise aufgezeichnet. Wenn Sie zurück zu Ihrem Dev-Zweig wechseln, tun Sie git stash pop. Dadurch werden diese Änderungen erneut angewendet und der Stash wird gelöscht, sodass er nicht länger in Ihrem Verlauf verbleibt.

Quelle

2012-04-12 14:02:46

Danke für diese Erklärungen.Ich gehe mit dem 'stash' anstelle des' clone', weil es aus irgendwelchen Gründen nicht so einfach ist, die Ordner in meiner Umgebung zu duplizieren. – Plouff

Ich denke, dass git stash ist, was Sie brauchen. Es gibt Hilfe darauf here.

Quelle

2012-04-12 14:03:44

Danke für den Link. Es wird hilfreich sein! – Plouff

git clone Ihr Master-Repository, und führen Sie die Regressionstests von dort. Denken Sie daran, git pull auszuführen, um Updates abzurufen. Und verpflichten Sie sich niemals zum geklonten Repository (oder seien Sie bereit, dieses so schnell wie möglich zum Master-Repository zusammenzuführen).

Quelle

2012-04-12 14:23:52 ydroneaud

Der 'Klon' scheint auch ein guter Weg zu sein. Es ist gut, diese Lösung zu kennen. Leider ist es nicht einfach für mich, diese Lösung zu verwenden. Vielen Dank! – Plouff

Mehrere gute Vorschläge hier. Mein erster Gedanke ist, zwei Klone zu haben, on on dev und one on master. Wechseln Sie einfach die Verzeichnisse (ähnlich dem, was Ydroneaud sagt).

Eine andere Möglichkeit, wenn Sie nur eine Regression ausführen möchten, besteht darin, git archive zu verwenden, um einen Snapshot abzurufen und damit zu testen. Gehen Sie in ein leeres Verzeichnis und zu tun:

git --git-dir=/my/dev/clone/.git archive master | tar xvf -

dann & Test bauen. Natürlich macht es Sinn, dies in ein Skript zu schreiben.

Quelle

2012-04-12 15:12:06 Kent

Habe ich richtig verstanden, wenn ich sage, dass dies eine Möglichkeit ist, den Master-Zweig zu klonen, ohne den Befehl 'clone' zu verwenden? – Plouff

Git - Best Practice: Wie man sehr oft zwischen Zweigen wechselt und multiple Commits vermeidet?

Antwort

Verwandte Themen