Ich verwende git als erstes Mal für ein Versionsverwaltungssystem. Ich beginne ein neues Projekt und experimentiere daher ein wenig mit den Technologien, die im Projekt verwendet werden (Hallo Welt Beispiele ...) Ich möchte so etwas wie einen "Spielplatz" Zweig erstellen. Ist es üblich, einen neuen Zweig "Spielplatz" zu erstellen oder soll ich einfach einen Ordner namens "Spielplatz" im Hauptzweig erstellen?
Grüße
Sie sollten einen neuen Zweig erstellen, wenn Sie Entwicklungsarbeiten ausführen, die etwas experimentell sind. Erstellen Sie in Ihrem Szenario also definitiv einen neuen Zweig und keinen Ordner innerhalb des Masters. Wenn Sie Ihre Sandbox-Arbeit als ein Verzeichnis im Master erstellt haben, wird es dort verbleiben, bis Sie es mit git entfernen. Die Tatsache, dass ein toter Code im Master-Zweig sitzt, ist keineswegs ideal, da er andere Entwickler verwirren und für die gesamte Lebensdauer der Anwendung faulenzen kann.
Wenn Ihr Team einen Fehler hatte, sollten Sie nicht wollen, dass sie Zeit damit verschwenden, die experimentelle Arbeit zu untersuchen, um festzustellen, ob der Fehler in diesem Verzeichnis existierte. Wenn Sie einen neuen Zweig erstellen, können Sie Ihre Änderungen vom Hauptzweig isolieren. Wenn das Experimentieren gut läuft, haben Sie immer die Möglichkeit, Ihre Änderungen in den Master-Zweig zu übernehmen. Wenn die Dinge nicht so gut laufen, können Sie den Zweig immer verwerfen oder in Ihrem lokalen Repository behalten.
Zweige können vielseitig verwendet werden und hängen ein wenig von Ihrem Arbeitsablauf ab. Zwei häufig verwendete Workflows sind:
Beide verwenden so genannte Themenzweige, um neue Features zu erstellen, die nach der Fertigstellung / Übernahme wieder zusammengeführt werden.
Github-Fluss ist ziemlich einfach und ist offensichtlich, was Github verwendet. Gitflow ist etwas komplizierter und eignet sich besser, wenn Sie mehrere Versionen einer App unterstützen müssen, wo Hotfixes angewendet werden können.
Am Ende ist es eine Frage der Präferenz, welche Art von Workflow Sie verwenden, aber weil das Erstellen von Zweigen in git sehr billig ist, spielt es keine Rolle, wie viele Zweige Sie erstellen (und eventuell wieder löschen).
Der übliche Weg besteht darin, den Master-Zweig als Live-Zweig zu verwenden. Dann machst du neue Zweige vom Master und arbeitest an ihnen (Feature Branches). Nachdem Sie Ihre Arbeit abgeschlossen haben, führen Sie die Änderungen zurück zu Ihrem Master.
Sie können neue Remote-Zweige wie einen Dev-Zweig erstellen und Ihre Änderungen mit diesem Zweig zusammenführen, wenn Sie nur eine Vorschau wünschen. Es gibt einige Methoden, aber es gibt viele Informationen auf Google.
Du solltest trotzig lernen, indem du experimentierst, aber in einem Spielplatz-Repo.
Ein Spielplatz Verzeichnis in einem Repo wird weniger profitieren.
Machen Sie ein Spiel, machen Sie einige Fehler, lernen Sie einige Dinge - löschen Sie es ein paar Mal und gehen Sie wild.
z.B.
%Vor%Ich würde auch empfehlen, eine Gabelung eines aktiven Projekts in der Sprache Ihrer Wahl von GitHub zu holen und mit dem Zusammenführen, Rebasieren usw. dort mit echtem Code zu beginnen.
Sie sollten in folgenden Fällen neue Zweige erstellen und daran arbeiten: -
Wenn Sie etwas in einer Sandbox-Umgebung ausprobieren / testen möchten.
Es ist eine gute Übung, Ihre Commits in der Natur kurz zu halten. Häufige Commits von Ihnen können den Entwicklungsbereich anderer stören. Daher ist es besser, Ihre Arbeit in einem Zweig zu erledigen und später Ihre Zweigstelle in den Hauptzweig zu integrieren. [Tipp] Denken Sie daran, Ihre Zweigstelle synchron mit der Hauptniederlassung zu halten, indem Sie die Hauptniederlassung häufig in Ihre Zweigstelle zusammenführen. Zu einem späteren Zeitpunkt haben Sie also nicht viel Zeug, das Sie manuell zusammenfügen können.
Sie möchten einen Fehler beheben. Es ist besser, es auf einem anderen Zweig zu lösen und es später zusammenzufügen.
Wenn Ihr Commit fehlschlägt / Ihren Build zerstört hat, ist der Produktions-Build nicht betroffen. Also bevorzuge ich mindestens zwei Zweige Dev-Zweig und Prod-Zweig. Wenn alles vollständig getestet wurde, füge deinen Entwicklungszweig dem Produktionszweig hinzu.
Tags und Links git branch versioning