2016-08-05 69 views
2

Ich mache einige SCSS Refactoring auf ein Projekt mit vielen SCSS-Dateien.Git Workflow: Zusammenführen von Zweigen unter Vermeidung von wiederholten Commit-Nachrichten

Hier ist mein Ansatz: um einen neuen Zweig für jeden SCSS-Datei Refactor zu erstellen.

Zum Beispiel erstelle ich eine neue Filiale scss-lint-refactor-chicken und Kasse, um es genannt wird, ich das Refactoring abzuschließen und sich verpflichten, die Änderungen (die Chicken.jsx und Chicken.scss und möglicherweise einige andere Dateien beinhalten würde).

Dann, ich checkout zu meistern, und den Zweig zusammenführen.

Der Master-Zweig endet mit einer Geschichte wie dieser nach oben:

* 75d48b2 - (7 minutes ago) Merge branch 'scss-lint-refactor-chicken' - Rory Smith 
|\ 
| * 9ea664f - (9 minutes ago) SCSS lint refactor chicken - Rory Smith 

Meine Fragen sind:

  1. Ist dies ein guter Ansatz für die Versionskontrolle für einen solchen Job Workflow?
  2. Wie kann ich den Prozess optimieren, so dass ich nicht 2 Commit-Nachrichten bekomme, die im Wesentlichen dasselbe auf verschiedene Arten sagen?
+0

Es klingt nach dem, was Sie suchen, ist _rebase_. Siehe [Merging versus Rebasing] (https://www.atlassian.com/git/tutorials/merging-vs-rebasing). –

Antwort

1
  1. Ja, es ist eine gute Möglichkeit, ein Versionskontrollsystem zu verwenden, so dass Sie Ihre Arbeit hinter oder zwei oder mehr Commits für das gleiche Refactoring verlassen können.

  2. Haben Sie keine Angst vor den Merge-Nachrichten. Sie sind dein Freund. Git wird nicht langsamer sein, weil Sie noch ein paar Commits haben. Wenn Sie denken, dass sie Ihre git log zu viel verschmutzen, verbergen sie:

    git log --no-merges 
    
1

Alternativ

Sie git rebase master laufen können, wenn Sie auf Ihrer Branche sind und dann git merge <branch> von Ihrem master Zweig laufen. Dies wird das merge Commit entfernen und könnte den Commit-Verlauf etwas sauberer machen.