Erhalten Sie ein umfassendes Verständnis der verschiedenen Arbeitsabläufe von Git

Dieser Artikel stellt Ihnen Git vor, stellt Ihnen die Grundkenntnisse von Git und verschiedene auf Git basierende Arbeitsabläufe vor. Ich hoffe, er wird Ihnen hilfreich sein!

In diesem Artikel können Sie lernen:

• Der Ursprung von Git
• Grundkenntnisse von Git
• Die grundlegende Art des Gitflow-Prozesses
• Verschiedene Workflows basierend auf Git

Bevor wir über Git Flow sprechen, haben wir Lass uns zuerst über etwas anderes reden

• Was ist eine Version?
  Die Version bezieht sich auf die Version beim Drucken, und die Version ist die gedruckte Buchversion; ein Titel, der verwendet wird, um verschiedene Formen, Zustände oder Inhalte derselben Sache zu beschreiben, die sich voneinander unterscheiden.
  Mit anderen Worten, solange alles differenziert ist, wird es das Konzept der Version beinhalten. Allerdings sollten die Versionen, über die wir hier sprechen, einschließlich der Dinge, über die wir später sprechen werden, alle sinnvolle Versionen sein Am 31. Januar wurde jeden Tag ein Planungsdokument überarbeitet. Am 1. Februar sagte Xiao Mings Partei A, dass die vorherige Version zu diesem Zeitpunkt für Xiao Ming besser sei. Vielleicht war es der letzte Plan, den Xiao Ming an Partei A geschickt hat, oder vielleicht war es der letzte Plan, von dem Partei A sagte, dass er in Ordnung sei, aber Xiao Ming erinnert sich möglicherweise nicht an das genaue Datum, an dem der Plan an Partei A überarbeitet wurde.

• Was sind die gängigen Versionskontrollen?
  Die Art und Weise, wie Kopierdateien nach Namen unterschieden werden, die Rückgängig-/Weiterleitungsfunktion dieses Editors und die Verwendung professioneller Tools wie SVN, Git usw. gehören alle zur Kategorie der Versionskontrolle. Verschiedene Versionskontrollen haben unterschiedliche Verwendungszwecke, z B. durch das Rückgängigmachen eines Texteditors, wie z. B. das Kopieren von Dateien, sodass neue und alte Dateien gleichzeitig vorhanden sein können, um einen einfachen Vergleich zu ermöglichen. Diese Methoden sind jedoch zu einfach und die Zwischenprozesse sind temporär und reichen nicht aus, um als Änderungshistorie-Referenz oder vollständige Version zu dienen. Dazu sind auch einige professionelle Tools erforderlich, wie z. B. zentralisierte Versionsverwaltungssysteme SVN, CVS, verteilte Versionsverwaltungssysteme BitKeeper, Git usw.

• Git-Entwicklungshintergrund

  Wie viele großartige Dinge im Leben wurde Git in einer Zeit großer Konflikte und Innovationen geboren. Das Linux-Kernel-Open-Source-Projekt hat eine große Teilnehmerzahl. Der überwiegende Teil der Wartungsarbeit für den Linux-Kernel wurde für die mühsame Aufgabe des Einreichens von Patches und des Speicherns von Archiven aufgewendet (1991–2002). Im Jahr 2002 begann das gesamte Projektteam, BitKeeper, ein proprietäres verteiltes Versionskontrollsystem, zur Verwaltung und Wartung von Code zu verwenden.
  Im Jahr 2005 endete die Partnerschaft zwischen dem kommerziellen Unternehmen, das BitKeeper entwickelt hatte, und der Linux-Kernel-Open-Source-Community, und sie nahmen der Linux-Kernel-Community das Recht zurück, BitKeeper kostenlos zu nutzen. Dies zwang die Linux-Open-Source-Community (insbesondere Linus Torvalds, der Erfinder von Linux), ein eigenes Versionssystem zu entwickeln, das auf den Erkenntnissen aus der Verwendung von BitKeeper basiert. Sie haben sich mehrere Ziele für das neue System gesetzt:

  • Geschwindigkeit
  • Einfaches Design
  • Starke Unterstützung für nichtlineare Entwicklungsmodelle (die Tausende von Zweigen der parallelen Entwicklung ermöglichen)
  • Vollständig verteilt
  • Fähig Sehr große Projekte effizient verwalten wie der Linux-Kernel (Geschwindigkeit und Datenvolumen) Seit seiner Einführung im Jahr 2005 ist Git von Tag zu Tag reifer geworden, ist äußerst benutzerfreundlich geworden und behält gleichzeitig die in seinen Anfängen gesetzten Ziele bei. Es ist schnell, eignet sich hervorragend für die Verwaltung großer Projekte und verfügt über ein unglaubliches nichtlineares Branch-Management-System (siehe Git-Branches).

• 1991 entwickelte Linux das Linux-System, ein Open-Source-Projekt. Die Quelldateien wurden per E-Mail mit angehängten Patches zum Schreiben und Entwickeln verschickt, und Linux selbst führte sie manuell zusammen

• Im Jahr 2002 führte BitKeeper hat eine Vereinbarung mit der Linux-Community getroffen, die es der Linux-Community ermöglicht, BitKeeper kostenlos zu testen. Der Inhalt der Vereinbarung betrifft eher den Schutz von BitKeeper.

• Im Jahr 2005 war BitKeeper unzufrieden mit der Linux-Community, weil sie den Inhalt der Vereinbarung zerstörte (um es ganz klar auszudrücken, sie dekompilierte BitKeeper und versuchte, eine gecrackte Version oder etwas anderes zu erstellen) und beendete die Zusammenarbeit;

• In Im selben Jahr wie 2005 verbrachte Linux zwei Wochen damit, Git zu entwickeln. Die erste Ausgabe verwendet Git, um Linux-Code in einem Monat zu verwalten )

  # 创建并进入 testGitFlow 目录
  # 此时 testGitFlow 就是我们的工作区(Workspace)，也就是工作目录
  
  $ mkdir testGitFlow && cd testGitFlow
  
  # 初始化 git 仓库
  # 此时目录中增加了 .git 目录，.git 目录就是 git 仓库，不属于工作区
  
  $ git init
  
  # 新增两个文件
  $ echo 111 > a.txt
  $ echo 222 > b.txt
  
  # 添加两个文件到暂存区/索引(Index)
  $ git add .
  
  # 把索引中的两个文件添加到版本库(Repository)
  $ git commit -m 'init'

Mehrere oben genannte Konzepte:

Arbeitsbereich

: Ein einfaches Verständnis ist unser Projektverzeichnis

Index

: Ein einfaches Verständnis ist der Bereich zum Speichern der einzureichenden Inhalte
Repository: Versionslager
Commit, Baum, Blob-Objekte

# 通过 git log 查看版本
$ git log

>
commit 2b304a56998989dbcfd77f370f4b43fcad9e5872 (HEAD -> master)
Author: huihuipan <huihuipan163@163.com>
Date:   Mon Feb 27 17:56:53 2023 +0800

    init


# 通过 git cat-file 查看 commit 信息

# 查看 commit 类型
$ git cat-file -t 2b304a
> commit

# 查看 commit 内容
$ git cat-file -p 10d717

>
tree 4caaa1a9ae0b274fba9e3675f9ef071616e5b209
author huihuipan <huihuipan163@163.com> 1677491813 +0800
committer huihuipan <huihuipan163@163.com> 1677491813 +0800

init

# 可以发现有 tree, author, committer 等信息
# 继续查看 tree 内容
$ git cat-file -t 4caaa1
> tree

$ git cat-file -p 4caaa1
>
100644 blob 58c9bdf9d017fcd178dc8c073cbfcbb7ff240d6c	a.txt
100644 blob c200906efd24ec5e783bee7f23b5d7c941b0c12c	b.txt

# 可以发现有 blob 信息
# 继续查看 blob 内容
$ git cat-file -t 58c9bd 
> blob

$ git cat-file -p 58c9bd 
> 111

# 可以看到里面存储的是 a.txt 的内容

Die oben genannten Ein Konzept: commit

: Commit zeichnet die übermittelte Version auf

tree

: Tree zeichnet die Verzeichnisstruktur und den Dateinamen unter verschiedenen Versionen auf
blob: Blob zeichnet den Dateiinhalt auf
Derzeit ist unsere Git-Projektstruktur wie folgt

Was passiert, wenn Sie eine Datei ändern und einen Commit senden?

1. Zunächst wird der Inhalt von a.txt von 111 auf 333 geändert. Zu diesem Zeitpunkt hat sich das Git-Warehouse nicht geändert, aber der Inhalt des Arbeitsbereichs und des Index stimmen nicht überein.
2. Führen Sie Folgendes aus: git add command
   1. Das Git Warehouse basiert auf dem neuen. Der Inhalt von a.txt (333) erstellt einen neuen Blob-Knoten und zeichnet den Inhalt von a.txt auf
   2. Der Index zeigt vom alten Blob auf den neuen Blob
3. Führen Sie den Git-Commit-Befehl aus.
   1. Entsprechend dem Status des Index wird ein Baumobjekt generiert.
   2. Generieren Sie ein neues Commit-Objekt basierend auf dem neu generierten Baumobjekt und dem vorherigen Commit-Objekt Commit-Objekt für das neue Commit-Objekt
HEAD, Branch, Tag

Branch : Es ist der Zeiger auf das Commit. Jedes Mal, wenn ein neues Commit übermittelt wird, zeigt der aktuelle Branch auf das letztes Commit;

HEAD: Es ist der Zeiger auf den Zweig. Wenn der Checkout einen Nicht-Zweig erreicht, wird eine Meldung angezeigt: Im Status des getrennten Kopfzeigers können Sie einige experimentelle Aktionen ausführen;

Tag

: Zeiger auf Commit, wird als Bezeichnung verwendet und normalerweise zum Aufzeichnen der festen Version verwendet. Kann auch als Alias ​​​​für das angegebene Commit verstanden werden; Aus dem Obigen können wir lernen, dass die Granularität der Versionsverwaltung von Git Wenn die Granularität klein ist, ist die anschließende Entwicklung und Erweiterung tatsächlich flexibler. Der Commit-Betrieb von Git ist ebenfalls sehr flexibel, so flexibel, dass es zu Unfällen kommen kann, wenn Sie nicht aufpassen. Checkout, Merge, Rebase, Fetch, Pull Funktionen, alle Schaltzweige haben exklusive Befehle

.

merge merge

:

switch

rebase rebase

:rebase ändert den Versionsverlauf, auch wenn der Inhalt vor und nach dem Rebase konsistent ist, ist die Version nicht mehr dieselbe Version ?

Indection

stammt aus einem Artikel "Ein erfolgreiches Git -Verzweigungsmodell" von

vincent diessen in 2010

Main -Branch

zwei Zweige, die die gesamte Version durchlaufen werden Lebenszyklus, also der langfristige Zweig:

Master-Zweig: zur Veröffentlichung Entwicklungszweig: zur Entwicklung Die Beziehung zwischen dem Master-Zweig und dem Develop-Zweig ist wie oben. Die gepunktete Linie weist darauf hin, dass die beiden Zweige nicht direkt miteinander verbunden sind, sondern über den Release-/Hotfix-Zweig, den Support-Zweig und die Feature-Zweige. Wird für die Bedarfsentwicklung verwendet

Ziehen Sie beim Entwickeln von Anforderungen den Feature-Zweig aus dem Entwicklungszweig heraus. Nachdem der Feature-Zweig entwickelt wurde (und es keine Probleme beim Entwicklungsselbsttest gibt), wird er wieder zusammengeführt Der Entwicklungszweig wird nach dem Zusammenführen gelöscht. Wenn später ein Fehler auftritt, wird er im Entwicklungszweig geändert.

Release-Zweige: werden für die Veröffentlichung verwendet

Wenn sich der Entwicklungszweig in einem relativ stabilen Zustand befindet, kann der Release-Zweig aus dem Entwicklungszweig gezogen werden, um die Veröffentlichung vorzubereiten. Der Release-Zweig führt keine Funktionsentwicklung durch , nur Fehlerbehebungen, bis Wenn es keine Probleme gibt, führen Sie es zur Veröffentlichung in den Master-Zweig zusammen. Führen Sie es gleichzeitig wieder in den Entwicklungszweig zusammen und löschen Sie den Release-Zweig.

• Hotfix-Zweige: werden zum Beheben von Produktionsproblemen verwendet.

Hotfix-Zweige werden zum Beheben von Fehlern verwendet, die in der Produktionsumgebung dringend behoben werden müssen. Ziehen Sie den Hotfix-Zweig aus dem Master-Zweig und führen Sie es nach der Reparatur wieder in den Hauptzweig ein. Veröffentlichen Sie es, führen Sie es in den Entwicklungszweig ein und löschen Sie es.

Schließlich den kompletten Gitflow überprüfen

Ergänzung

Im Jahr 2020 hat Vincent Driessen eine Reflexionsnotiz hinzugefügt, grob gesagtGit FlowDieses Modell wird kontinuierlich ausgeliefert Es scheint kompliziert, du können erwägen, Github Flow zu verwenden, anstatt Git Flow in das Projekt zu zwingen.

Nach Git Flow optimierte Adam Ruka die technischen Details von Git Flow und schlug One Flow

Github Flow

vor.

versus Git Flow , Github Flow haben nur einen Hauptzweig und der PR-Prozess wird über die Github-Plattform hinzugefügt: Wenn Sie eine bestimmte Funktion entwickeln, ziehen Sie den Feature-Zweig aus dem Master-Zweig heraus, reichen Sie nach Abschluss der Funktion eine PR ein und lassen Sie sie vom zuständigen Personal überprüfen. Während des Überprüfungszeitraums können Sie die Funktion weiterhin einreichen, bis bestätigt wird, dass keine vorhanden ist Probleme und übergeben Sie die PR, um den Feature-Zweig in den Master zusammenzuführen. Verzweigen Sie, um

GitLab Flow

GitLab Flow freizugeben. Verwenden Sie den master-Zweig als Entwicklungszweig, basierend auf dem master-Zweig um den Produktionszweig Produktion
GitLab Flow freizugeben, wurden die folgenden Zweigdefinitionen hinzugefügt:
Umgebungszweig : Wird verwendet, wenn Sie verschiedene Versionen in verschiedenen Umgebungen veröffentlichen müssen
Release-Zweig : Wird verwendet, wenn das Projekt verschiedene Versionen veröffentlichen muss. Nach der Deklaration eines Release-Zweigs werden diese Zweige nur mit schwerwiegenden Fehlerbehebungsaktualisierungen zusammengeführt. Kontinuierliche Veröffentlichung

gitlab-flow empfiehlt die Verwendung des Master-Zweigs für die Entwicklung und den Aufbau eines Produktionszweigs basierend auf dem Master-Zweig für die Veröffentlichung. Außerdem wird das Konzept von Umgebungszweigen vorgeschlagen, die entsprechend Schicht für Schicht zusammengeführt werden Verschiedene Umgebungen und schließlich zur Veröffentlichung in der Produktion zusammengefasst

Versionsfreigabe

Wenn Ihr Projekt verschiedene Versionen veröffentlichen muss, ist der Versionsfreigabemodus von gitlab-flow möglicherweise besser geeignet. Verschiedene Versionen verfügen über unterschiedliche Release-Zweige.

Aone Flow

Aone-Flow basiert auf dem Master-Zweig und außer dem Master-Zweig gibt es temporäre Zweige. Die Umgebungszweige werden basierend auf dem Master-Zweig herausgezogen. Es besteht keine Verbindung zwischen den Umgebungszweigen und sie werden unabhängig voneinander entwickelt. Die Umgebungszweige dürfen nicht direkt geändert werden, sondern werden durch Zusammenführen verschiedener Feature-Zweige kombiniert. Der Feature-Zweig wird erst gelöscht, wenn er mit dem Release-Zweig zusammengeführt wird. Ein Vorteil besteht darin, dass die Granularität des Vorgangs höher und besser kontrollierbar ist. Der Nachteil besteht darin, dass der Versionsverlauf möglicherweise inkonsistent ist, selbst wenn der Inhalt des Umgebungszweigs derselbe ist.

So wählen Sie die Versionskontrolle aus

Ausgehend von Gitflow ermöglicht Gitflow eine geführte Verwendungsmethode für Git Komplexität von Gitflow.

gitlab-flow bietet eine eigene Kompromisslösung für die zu komplexen oder zu einfachen Methoden von Gitflow und Github-Flow und bietet außerdem Lösungen für zwei Bereitstellungsmethoden (kontinuierliche Bereitstellung, Versionsbereitstellung).

Schließlich wird auch AoneFlow eingeführt, eine Lösung mit freierer Betriebsgranularität.

Tatsächlich gibt es keine einheitliche Lösung. Verschiedene Teams/Projekte haben ihre eigenen speziellen Situationen. Für unterschiedliche Situationen ändert sich auch der Ablauf, und die geeignete Lösung ist die beste.

Abschließend: Denken Sie immer daran, dass es keine Panik gibt. Seien Sie nicht selbsthassend.

Zitat von Vincent Driessen: „Denken Sie immer daran, dass es kein Allheilmittel gibt. Entscheiden Sie nicht selbst.“

Weitere Programmierkenntnisse finden Sie unter: Programmiervideos ! !

Das obige ist der detaillierte Inhalt vonErhalten Sie ein umfassendes Verständnis der verschiedenen Arbeitsabläufe von Git. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!