Zusammenfassung der Wissenspunkte des Git Remote Warehouse (Github).

Dieser Artikel bringt Ihnen relevantes Wissen über Git, das hauptsächlich die relevanten Inhalte zu Remote-Warehouses vorstellt. Es gibt keinen zentralen Server wie SVN. Schauen wir uns einige Probleme an, die bei der Verwendung von Github als Remote-Warehouse auftreten hilft allen.

Empfohlenes Lernen: „Git Learning Tutorial“

Git Remote Warehouse (Github)

Git verfügt nicht über einen zentralen Server wie SVN.

Die Git-Befehle, die wir derzeit verwenden, werden alle lokal ausgeführt, wenn Sie Ihren Code teilen oder über Git mit anderen Entwicklern zusammenarbeiten möchten. Anschließend müssen Sie die Daten auf einem Server ablegen, mit dem sich andere Entwickler verbinden können.

In diesem Beispiel wird Github als Remote-Warehouse verwendet. Sie können zuerst unser kurzes Github-Tutorial lesen.

Remote-Warehouse-Befehl
1. Zeigen Sie die aktuelle Remote-Bibliothek an

2. Fügen Sie ein Remote-Warehouse hinzu
Führen Sie git remote add aus, um ein neues Remote-Git-Warehouse hinzuzufügen, und geben Sie eine praktische Abkürzung an:

3. $ git fetch
Dieser Befehl greift auf das Remote-Repository zu und ruft alle Daten ab, die Sie noch nicht haben. Sobald die Ausführung abgeschlossen ist, verfügen Sie über Verweise auf alle Zweige in diesem Remote-Repository, die jederzeit zusammengeführt oder angezeigt werden können.

Alle Zweige unter origin werden kopiert

Der Befehl git fetch lädt nur Daten in Ihr lokales Repository herunter – er führt Ihre aktuelle Arbeit nicht automatisch zusammen oder ändert sie. Sie müssen es manuell in Ihren Job integrieren, wenn Sie fertig sind.
Der Befehl „git pull“ ruft den Remote-Branch automatisch ab und führt ihn in den aktuellen Branch ein.
Standardmäßig stellt der Befehl „git clone“ den lokalen Master-Branch automatisch so ein, dass er den Master-Branch des geklonten Remote-Warehouse (oder den Standard-Branch mit einem anderen Namen) verfolgt ). Beim Ausführen von git pull werden normalerweise die Daten vom ursprünglich geklonten Server abgerufen und automatisch versucht, sie mit dem aktuellen Zweig zusammenzuführen.
3. Git Push zum Remote Warehouse

Dieser Befehl kann nur wirksam werden, wenn Sie Schreibrechte auf dem Klonserver haben und noch niemand zuvor gepusht hat. Wenn Sie gleichzeitig mit jemand anderem klonen und dieser zuerst zum Upstream pusht und Sie dann zum Upstream pushen, wird Ihr Push ohne Frage abgelehnt. Sie müssen sich ihre Arbeit schnappen und sie mit Ihrer verschmelzen, bevor Sie sie vorantreiben können.
4. Ein Remote-Repository anzeigen
Wenn Sie weitere Informationen zu einem Remote-Repository anzeigen möchten, können Sie den Befehl git remote show verwenden.

5. Umbenennen des Remote-Warehouses
git remote rename, um die Abkürzung eines Remote-Warehouses zu ändern
6. Entfernen des Remote-Warehouses
git remote Remove oder git remote rm

7. Tag: Sie können dem Warehouse A geben Bestimmte Commits im Verlauf werden markiert, um ihre Wichtigkeit anzuzeigen. Es ist repräsentativer, dass Leute diese Funktion verwenden, um Release-Knoten zu markieren
1) Tags auflisten

2) git tag -l/list Wildcard-Methode zum Auflisten von Tags

3) Lightweight-Tags: Es handelt sich lediglich um einen Verweis auf eine bestimmte Sache Beim Commit wird im Wesentlichen die Commit-Prüfsumme in einer Datei gespeichert – es werden keine weiteren Informationen gespeichert

4) Annotiertes Tag: ein vollständiges Objekt, das in der Git-Datenbank gespeichert ist. Sie können überprüft werden und enthalten den Namen, die E-Mail-Adresse, das Datum und die Uhrzeit des Taggers. Außerdem gibt es Tag-Informationen.

5) Späteres Tagging: Tag Historische Projekte

6) Geteilte Tags: Der Befehl „git push“ überträgt keine Tags an den Remote-Warehouse-Server. Sie können „git push origin“ ausführen.

git push origin --tags：将会把所有不在远程仓库服务器上的标签全部传送到那里。
![Zusammenfassung der Wissenspunkte des Git Remote Warehouse (Github).](https://img-blog.csdnimg.cn/498567ecae294ae9af392a975334650f.png)

7) Um das Tag in Ihrem lokalen Repository zu löschen
git tag -d

Beachten Sie, dass der obige Befehl dieses Tag nicht aus einem Remote-Repository entfernt. Sie müssen git push :refs/tags/ verwenden. Aktualisieren Sie Ihr Remote-Repository Repository:

Beachten Sie, dass der obige Befehl dieses Tag nicht aus einem Remote-Repository entfernt.
Sie müssen die erste Variante verwenden, nämlich git push :refs/tags/ :

$ git push origin :refs /tags/v1. 4-lw
Die Bedeutung der obigen Operation besteht darin, den Nullwert vor dem Doppelpunkt in den Remote-Tag-Namen zu verschieben und ihn dadurch effizient zu löschen.
Die zweite, intuitivere Möglichkeit, Remote-Tags zu löschen, ist:
$ git push origin --delete
8. Git-Branch-Verwaltung
Hinweis: Git-Branch listet alle aktuellen Branches auf: Das *-Zeichen vor dem Branch bedeutet, dass jetzt geprüft wird
1) Git Branch Testing erstellt einen Testzweig.
2) Git Checkout Testing wechselt die Zweige und zeigt den aktuellen Zweig an. Sie können mit HEAD auf den aktuellen Zweig zeigen + Zweige separat testen, und der Kopfzeiger bewegt sich vorwärts
Der Benchmark beider Zweige ist 9623a70fe. Nach dem separaten Senden ändern sich ihre jeweiligen Zeiger. Führen Sie git log --oneline --decorate --graph -- aus. all , werden Ihr Übermittlungsverlauf, die Zeiger auf jeden Zweig und die Zweigzweige des Projekts ausgegeben.

Fork-Situation:

Branch merge git merge [Keine Änderungen am Public Opinion-Branch, neue Einreichungen im Hotfix-Branch] – Drei-Parteien-Fusion Hotfix zieht basierend auf dem Public Opinion-Test-Branch, generiert Einreichungen im Hotfix, Überprüfen Sie die Einreichungen des Hotfix-Zweigs. Die ID lautet 85bb*, wechseln Sie zurück zum Zweig der öffentlichen Meinung, führen Sie git merge aus und stellen Sie fest, dass die Einreichungs-ID des Zweigs der öffentlichen Meinung ebenfalls auf 85bb* erweitert wurde, die vom Hotfix-Zweig generiert wurde

Darstellung der Änderungen im Zweig „Öffentliche Meinung“ und im Zweig „Hotfix“:

Branch merge git merge [Zweig „Public Opinion“] /Testing-Zweig generiert neue Einreichungen】
Der Test wird basierend auf dem Zweig „Public Opinion Test“ und dem Zweig „Test/Öffentliche Meinung“ gezogen Der Zweig wird geändert, um Einreichungen zu generieren. Nachdem der Zweig für die öffentliche Meinung den Inhalt des Zweigs für die öffentliche Meinung zusammengeführt hat, wird er zum Zweig für die öffentliche Meinung umgeschaltet. Wenn der Zweig für die öffentliche Meinung zusammengeführt wird, wird festgestellt, dass der Zweig für die öffentliche Meinung direkt einen neuen Zweig generiert Commit-ID41b1* und die entsprechenden d804 und 85 im Zweig der öffentlichen Meinung werden nicht zusammengeführt. Zu diesem Zeitpunkt entspricht die neue ID den beiden übergeordneten IDs Da4 des Zweigs „Testen“ und 85b des Zweigs „Öffentliche Meinung“. ) git checkbox Testing 2) git merge Public Opinion Branch

4）git branch -v 查看每个分支的最后一次提交

5）git branch --merged/–no-merged 过滤这个列表中已经合并或尚未合并到当前分支的分支

6)git branch -d
包含了还未合并的工作，尝试使用 git branch -d 命令删除它时会失败,除非用-D

9、远程分支
1） git ls-remote 来显式地获得远程引用的完整列表
通过 git remote show 获得远程分支的更多信息

2)origin/master和master区别

master ： 它代表本地的某个分支名。
origin master 代表着两个概念，前面的 origin 代表远程名，后面的 master 代表远程分支名
origin/master 本地分支，是从远程拉取后，在本地建立的一份拷贝【是用来和远程分支对应的，一般不可见】
 举几个例子可能会更加清晰地说明问题：
① 执行 git fetch origin master 时，它的意思是从名为 origin 的远程上拉取名为 master 的分支到本地分支
 origin/master 中。既然是拉取代码，当然需要同时指定远程名与分支名，所以分开写。
 ②执行 git merge origin/master 时，它的意思是合并名为 origin/master的分支到当前所在分支。既然是分支的合并，当然就与远程名没有直接的关系，所以没有出现远程名。需要指定的是被合并的分支。
 ③执行 git push origin master 时， 推送本地的 master 分支到远程origin， 
④ 一次性拉取多个分支的代码：git fetch origin master dev1 dev2
 ⑤ 一次性合并多个分支的代码：git merge origin/master 分支1 分支2 分支3

2）如果远程仓库有人提交内容，那么远程仓库就会向前移动，而本地origin/master如果不拉取，将还保持不动，如果希望本地同远程保持一致，可以通过git fetch拉取远程仓库数据，
git fetch
3) git push origin 分支名
推送本地的 舆情测试 分支，将其作为远程仓库的 舆情测试 分支
如果并不想让远程仓库 上的分支叫做 舆情测试 ，可以运行 git push origin 舆情测试 :test0421 来将本地的 舆情测试 分支推送到远程仓库上的 test0421 分支。


4)checkout 的操作
通过 git checkout test0421 会把分支切换到test0421分支上

这个操作会处于‘detached Head’ 状态，在这种状态下不会修改origin/test0421上的数据，可以修改并提交做一些实验性的操作，但是切换回test0421分支后，再次从test0421切换回origin/test0421时，之前的改变不会同步，因为origin/test0421 是用户只读的
5）git push origin --delete 分支名 删除远程仓库分支【本地仓库还有数据】

6）rebase变基：使用 rebase 命令将提交到某一分支上的所有修改都移至另一分支上，就好像“重新播放”一样。

首先找到这两个分支（即当前分支 Test0421、变基操作的目标基底分支 Test0420） 的最近共同祖先 85bb，然后对比当前分支相对于该祖先的历次提交，提取相应的修改并存为临时文件， 然后将当前分支指向目标基底 3467, 最后以此将之前另存为临时文件的修改依序应用

Test0420 使用git merge 合并Test0421内容，结果两个分支完全一致，可以发现提交记录没有出现分拆，而是保持在一条直线上【可以比较前面get merge环节中结果出现分叉】

rebase时一系列提交按照原有次序依次应用，只是当前分支的提交id值改变

merge时多次提交合并成一次，生成新的提交id
总结：无论是通过变基，还是通过三方合并，整合的最终结果所指向的快照始终是一样的，只不过提交历史不同罢了。 变基是将一系列提交按照原有次序依次应用到另一分支上，而合并是把最终结果合在一起。

推荐学习：《Git学习教程》

Das obige ist der detaillierte Inhalt vonZusammenfassung der Wissenspunkte des Git Remote Warehouse (Github).. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!