Ich bin ein Jungstudent an einer Grundschule. Während der Projektentwicklung habe ich Git-Technologie verwendet. Jetzt fasse ich Git zusammen: Jeder ist willkommen, miteinander zu kommunizieren.
1. Der Git-Workflow ist in der folgenden Abbildung dargestellt
2. Einige Grundkonzepte
.git-Verzeichnis: wird generiert, wenn git init zum Initialisieren eines Git-Warehouses verwendet wird. Das versteckte Git-Verzeichnis speichert Informationen wie Dateiänderungsdatensätze des gesamten Projekts.
Arbeitsbereich: Es kann als das Verzeichnis verstanden werden, in dem sich das lokale Git-Warehouse befindet, das auch das Projektverzeichnis ist.
Staging-Bereich: Alle über den Befehl git add hinzugefügten Dateien werden im Staging-Bereich gespeichert, bei dem es sich tatsächlich um die Indexdatei im .git-Verzeichnis handelt.
Repository: Das ist das gesamte Git-Warehouse.
Die Beziehung zwischen den dreien: Der Arbeitsbereich ist Ihr Entwicklungsverzeichnis, alle bearbeiteten Dateien werden über Git Add zum Staging-Bereich hinzugefügt und dann über Git Commit an das lokale Git-Repository übermittelt Befehl und dann über Git Push an das Remote-Git-Repository senden.
Die reguläre Git-Warehouse-Struktur ist wie folgt
git@git.xxx.com:user/project_name.git
|-master (Master-Zweig, synchronisiert mit Online-Code)
|-develop (Entwicklungszweig, nachdem die Funktionsentwicklung abgeschlossen ist, wird sie zuerst mit der Entwicklung zusammengeführt und dann wird die Entwicklung mit dem Master zusammengeführt)
|-feature (temporärer Zweig (Funktionszweig). Um beispielsweise eine bestimmte Funktion zu entwickeln, können Sie einen neuen Feature-Zweig erstellen und den Feature-Zweig nach Abschluss in „Develop“ zusammenführen)
|———— feature/update_online_pay_api
|———— feature/add_new_feature..
|———— …
|-release (temporärer Zweig (Vorabversionszweig), erstellen Sie nach der Entwicklung und dem Testen einen neuen Release-Zweig zum Testen und führen Sie ihn nach Abschluss in den Master zusammen und entwickeln Sie ihn)
|———— release/update_online_pay_api
|———— …
|-hotfix (temporärer Zweig (Hot-Modification-Zweig), der im Allgemeinen für die Notfalländerung kurzfristiger Aufgaben wie Bug-Zweige verwendet wird und nach Abschluss der Änderung in Master und Entwicklung zusammengeführt wird)
|———— Hotfix /handler_pay_bug
|————…
Über die Benennungsregeln für Zweige: Sehen Sie sich den Namen an und kennen Sie den Namen. Temporäre Zweige können durch „/“ oder „-“ usw. getrennt werden. Es gibt keine zwingende Anforderung.
Wenn Sie eine Produktanforderung erhalten und mit der Entwicklung beginnen, läuft der Git-Prozess wie folgt ab:
Zuerst müssen Sie das Projekt im Remote-Git-Warehouse mit Ihrem lokalen synchronisieren . Der Prozess ist wie folgt:
cd ~/workspace/git/ // 进入你个人的工作目录
mkdir project_name // 新建一个目录用于存放代码，名称可以和远程仓库名称一样
cd project_name // 进入你新建的目录
git init // 使用git初始化这个目录为一个git仓库
git remote add origin git@github.com:22th/oh-my-zsh.git // 关联本地仓库到一个远程仓库
git fetch --depth=1 // 更新远程仓库的一些信息到本地，比如分支信息等
git checkout -b master origin/master // 检出一个分支master并关联远程的master分支
git pull // 更新本地仓库代码
Nach dem Login kopieren
Durch den oben genannten Prozess können Sie das Remote-Projekt mit dem lokalen Master-Zweig synchronisieren. Im Allgemeinen haben Sie diese Berechtigung nicht. Nachdem Sie den Code mit dem lokalen Code synchronisiert haben, müssen Sie entsprechend den Geschäftsanforderungen einen neuen Entwicklungszweig erstellen. Der Name kann an Ihre Anforderungen angepasst werden. Wenn Sie beispielsweise ein neues Feature entwickeln möchten, erstellen Sie ein Feature-xxx Wenn Sie einen Fehler beheben möchten, können Sie einen hotfix-xxx-Zweig erstellen. Es wird nicht empfohlen, lokal einen neuen Zweig zu erstellen. Sie sollten einen neuen Zweig im Hintergrund der Git-Warehouse-Verwaltung erstellen und ihn dann lokal auschecken. Das Erstellen eines neuen Zweigs im Verwaltungshintergrund ist sehr einfach, daher werde ich nicht auf Details eingehen.
Dann überprüfen Sie Ihren neu erstellten Zweig lokal. Der Befehl lautet wie folgt: git checkout -b feature-xxx origin/feature-xxx
Der nächste Schritt ist Ihr glücklicher Entwicklungsprozess. Entwickeln Sie Ihren eigenen Zweig, testen Sie ihn und senden Sie ihn dann ab Die verwendeten Git-Befehle lauten wie folgt:
git add <file> // 将工作区修改添加到暂存区，加上 --all 参数表示将所有修改添加到暂存区
git commit -m “msg” // 将暂存区的修改添加到版本库
git push -u origin feature-xxx // 将本地仓库中的修改推送到远程
git status // 查看当前工作区间状态
git log // 查看历史commit
git checkout -- <file> // 用最后一次commit的文件替换当前工作区间的文件
git reset --hard // 丢弃工作区间所有修改，回滚到上一个commit状态
git checkout <版本号> // 回滚到指定版本
Nach dem Login kopieren
Um Funktionen zu entwickeln, müssen Sie sie online testen und veröffentlichen. Der Prozess ist wie folgt:
1 Im Git-Warehouse-Management-Hintergrund wird der Zweig, der auf Ihrem Feature-xxx-Zweig basiert, hauptsächlich zum Testen verwendet.
2. Nachdem der Release-xxx-Test in Ordnung ist, können Sie ihn in den Master- und Entwicklungszweigen zusammenführen. Im Allgemeinen senden Sie eine Zusammenführungsanforderung über den Git-Warehouse-Management-Hintergrund und warten auf die Bestätigung durch das zuständige Managementpersonal Führen Sie ihn mit dem Master zusammen und senden Sie die Zusammenführungsanforderung. Führen Sie zuvor zuerst den Master-Zweig zusammen, um sicherzustellen, dass der neu geänderte Code auf dem Master mit Ihnen synchronisiert wird. Beim Zusammenführen des Masters können Konflikte auftreten. Finden Sie die widersprüchlichen Dateien, lösen Sie sie und führen Sie einen Commit durch. Das Konfliktformat ist wie folgt:
<<<<<<< HEADln -s ../statics xxx
=======ln -s ../statics statics
>>>>>>> master
Nach dem Login kopieren
wobei «««< Der Inhalt zwischen HEAD und ======= stellt den Code in Ihrem Zweig dar, während ======= und »» »> Master repräsentiert den Code im Master-Zweig. Der Prozess der manuellen Konfliktlösung besteht dann darin, den Code zu bestätigen, den Sie behalten möchten, und den anderen zu löschen . Das heißt, wenn Sie Ihren lokalen Code behalten möchten, dann ist es so:
<<<<<<< HEAD （删除）
ln -s ../statics xxx （保留）
======= （删除）
ln -s ../statics statics （删除）
>>>>>>> master （删除）
Nach dem Login kopieren
保留 «««git commit -am “解决冲突”。
3、好了，其他的工作就是运维人员来处理了。一般是这样的，release-xxx分支测试完成并解决所有冲突后，运维发布人员merge到master分支，然后通过 git d<a href="http://www.php.cn/wiki/109.html" target="_blank">if</a>f 608e120 4abe32e --name-only | xargs zip update.zip 命令打包差异文件，然后发布这个差异文件包就可以啦，不需要所有文件都覆盖线上文件。
到这里，整个git项目开发流程就已经非常清楚了。git还有很多高级功能，比如文件对比、文件历史修改记录、关联多个远程仓库等等需要你慢慢去摸索了。使用git要灵活运用分支，因为git新建切换分支的成本非常低，因为git新建分支不是想svn那样吧整个目录复制一遍，然后通过索引文件等更高级的方式来处理，效率高太多。
在推荐个git图形化管理工具：
source tree， mac和windows都有。
If you liked this article and think others should read it, please follow webff
Das obige ist der detaillierte Inhalt vonDetaillierte Erklärung von Git – das Team entwickelt schnell Artefakte. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
