12 erweiterte Git-Befehle

Wie wir alle wissen, ist Git derzeit führend im Bereich der verteilten Versionskontrolle, und rund um Git hat sich ein komplettes Ökosystem gebildet. Um Git zu lernen, besteht der erste Schritt darin, den grundlegenden Arbeitsablauf von Git zu erlernen. Im Vergleich zu herkömmlichen Versionskontrollsystemen wie SVN ist Git ein leistungsstarkes Tool für die verteilte Versionskontrolle. Zu den häufig verwendeten Befehlen bei der Verwendung von Git gehören Pull, Commit, Push usw., die sehr einfach zu sein scheinen. Manchmal werden Sie jedoch auf Zusammenführungskonflikte stoßen, die von Git markiert werden und von Ihnen verlangt werden, sie manuell zu lösen. Manchmal übergeben Sie Code versehentlich an den falschen Zweig und übertragen ihn in das Remote-Repository. Es kann auch vorkommen, dass Sie zu einem anderen Zweig wechseln müssen, Git dies jedoch nicht zulässt, da noch nicht gespeicherte Änderungen vorhanden sind. Was ist, wenn Sie den Code durch einen Commit aus einem anderen Zweig patchen müssen? In diesem Artikel werden 12 erweiterte Git-Befehle vorgestellt. Die ordnungsgemäße Verwendung dieser Befehle kann die Effizienz der Git-Anwendung erheblich verbessern.

1. Verwenden Sie Rebase anstelle von Merge, um Upstream-Änderungen abzurufen.

Die Zweigzusammenführung wird als Merge-Commit aufgezeichnet, was sehr aussagekräftig ist. Dies könnte beispielsweise verwendet werden, um anzuzeigen, dass eine neue Funktion in einen Release-Zweig integriert wurde. Wenn jedoch mehrere Teammitglieder an einem Projekt arbeiten und regelmäßige Git-Pulls verwenden, um Zweige zu synchronisieren, wird die Commit-Zeitleiste mit unnötigen Merge-Commits verschmutzt. Ein besserer Ansatz besteht darin, git rebase zu verwenden, um einen Feature-Zweig auf den Master-Zweig umzubasieren:

$ git checkout feature
$ git rebase master

Dadurch wird der gesamte Feature-Zweig an den Startpunkt des Master-Zweigs verschoben und alles neu zusammengeführt Änderungen an der Master-Branch-Übermittlung. Im Vergleich zur Verwendung von Merge-Commits wird beim Rebasing jedoch der Projektverlauf neu geschrieben, indem für jeden Commit im ursprünglichen Zweig ein neuer Commit erstellt wird. Der Hauptvorteil der Umbasierung besteht darin, dass Sie einen saubereren Projektverlauf erhalten. Darüber hinaus gibt es hier einige Diskussionen über die Fallstricke einer Umbasierung.

　2. Zusammenführungskonflikte nach der Ausführung von Git Rebase lösen

　Je größer die Fähigkeit, desto größer die Verantwortung. Bei der Durchführung einer Git-Rebase können Zusammenführungskonflikte auftreten. Ein Zusammenführungskonflikt bedeutet, dass zwei Commits dieselbe Zeile derselben Datei geändert haben und Git nicht weiß, welche Änderung anzuwenden ist. Dies führt zu einer Fehlermeldung wie dieser:

Git gibt Ihnen drei Optionen, um den Commit zu beheben, der den Konflikt verursacht hat (fa39187):

OK Ausführen git rebase --abort, um das Rebase vollständig abzubrechen. Dadurch werden die Rebase-Änderungen abgebrochen und der Zweig wird in den Zustand zurückversetzt, in dem er sich vor der Ausführung von git rebase befand.

Sie können git rebase --skip ausführen, um den Commit vollständig zu ignorieren. Auf diese Weise werden durch den betreffenden Commit eingeführte Änderungen nicht zum Verlauf hinzugefügt.

Konflikte können mit denselben Standardschritten wie Zusammenführungskonflikte gelöst werden.

　3. Änderungen vorübergehend speichern

　Während der Arbeit sind einige Dinge oft in einem chaotischen Zustand. Was soll ich tun, wenn ich zu diesem Zeitpunkt zu einer anderen Filiale wechseln muss? Git lässt dies nicht zu, da noch nicht gespeicherte Änderungen vorhanden sind. Ehrlich gesagt möchten Sie kein halbfertiges Produkt einreichen und es später überarbeiten. Die Lösung für dieses Problem ist die Verwendung des Befehls git stash. Stash empfängt den aktuellen Status des Arbeitsverzeichnisses (z. B. geänderte Tracking-Dateien und Änderungen am Staging-Bereich usw.) und speichert ihn im unvollendeten Änderungsstapel, sodass er später jederzeit geändert werden kann. Sie können den folgenden Befehl verwenden, um Ihre Arbeit zu verstecken:

$ git stash
Arbeitsverzeichnis und Indexstatus WIP für Funktion gespeichert: 3fc175f fix Race Condition
HEAD ist jetzt bei 3fc175f fix Race Condition

Jetzt ist das Arbeitsverzeichnis sauber:

$ git status
# On branch feature
nothing to commit, working directory clean

Jetzt können Sie sicher zwischen Zweigen wechseln, um andere Dinge zu erledigen. Aber keine Sorge, die temporären Commits sind immer noch da:

$ git stash list
stash@{0}: WIP on feature: 3fc175f fix race condition

Später, nach der Rückkehr zum Feature-Zweig, können Sie alle temporären Änderungen abrufen:

$ git stash pop
On branch feature
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
     modified:   index.html
Dropped refs/stash@{0} (ac2321cc3a33ba712b8e50c99a99d3c20da9d6b8)

Bezüglich Staging , es stehen einige andere Optionen zur Verfügung, wie folgt:

$ git stash save "describe it"   # give the stash a name
$ git stash clear                # delete a stashed commit
$ git stash save --keep-index    # stash only unstaged files

4. Einen bestimmten Remote-Zweig klonen

Wenn Sie einen bestimmten Remote-Zweig aus dem Remote-Repository klonen möchten Zweig? Normalerweise würden Sie git clone verwenden, aber dadurch werden auch alle anderen Zweige geklont. Eine bequeme Möglichkeit ist die Verwendung von git remote add:

$ git init  
$ git remote add -t-f origin$ git checkout

5. Führen Sie Cherry-Pick-Remote-Commits in Ihrem eigenen Zweig zusammen.

Darüber hinaus, wenn Sie nur das Remote-Repository zusammenführen möchten. Wie ein bestimmtes Commit in einem eigenen Zweig zusammenführen? Sie können Git Cherry-Pick verwenden, um einen Commit mit einem bestimmten SHA-Wert auszuwählen und ihn in den aktuellen Zweig einzufügen:

$ git cherry-pick

6. Wenden Sie Patches aus nicht verwandten lokalen Repositorys an

Was soll ich tun? Was kann ich tun, wenn ich den übermittelten Patch von einem anderen unabhängigen lokalen Lager auf das aktuelle Lager anwenden muss? Die Antwort ist der folgende Befehl:

$ git --git-dir=/.git format-patch -k -1 --stdout| git am -3 -k

7. Ignorieren Sie Änderungen in Tracking-Dateien

　　如果你和你的同事操纵的是相同分支，那么很有可能需要频繁执行git merge或是git rebase。不过，这么做可能会重置一些与环境相关的配置文件，这样在每次合并后都需要修改。与之相反，你可以通过如下命令永久性地告诉Git不要管某个本地文件：

$ git update-index --assume-unchanged

8. 每隔X秒运行一次git pull

　　通常，合并冲突出现的原因在于你正在工作的本地仓库不再反映远程仓库的当前状态。这正是我们为什么每天早晨要首先执行一次git pull的缘故。此外，你还可以在后台通过脚本（或是使用GNU Screen）每隔X秒调用一次git pull：

$ screen
$ for((i=1;i<=10000;i+=1)); do sleep X && git pull; done

　　9. 将子目录分隔为新的仓库

　　有时，你可能需要将Git仓库中某个特定的目录转换为一个全新的仓库。这可以通过git filter-branch来实现：

$ git filter-branch --prune-empty --subdirectory-filtermaster
# Filter the master branch to your directory and remove empty commits
Rewrite 48dc599c80e20527ed902928085e7861e6b3cbe6 (89/89)
Ref 'refs/heads/master' was rewritten

　　现在，仓库会包含指定子目录中的所有文件。虽然之前的所有文件都会被删除，但他们依旧存在于Git历史中。现在可以将新的本地仓库推送到远程了。

　　10. 清理

　　有时，Git会提示“untracked working tree files”会“overwritten by checkout”。造成这种情况的原因有很多。不过通常来说，我们可以使用如下命令来保持工作树的整洁，从而防止这种情况的发生：

$ git clean -f     # remove untracked files
$ git clean -fd    # remove untracked files/directories
$ git clean -nfd   # list all files/directories that would be removed

11. 将项目文件打成tar包，并且排除.git目录

　　有时，你需要将项目副本提供给无法访问GitHub仓库的外部成员。最简单的方式就是使用tar或zip来打包所有的项目文件。不过，如果不小心，隐藏的.git目录就会包含到tar文件中，这会导致文件体积变大；同时，如果里面的文件与接收者自己的Git仓库弄混了，那就更加令人头疼了。轻松的做法则是自动从tar文件中排除掉.git目录：

$ tar cJf.tar.xz/ --exclude-vcs

　　12. 查找修改者

　　最后，如果出现混乱的情况，你一定想要找出是谁造成的。如果生产服务器宕机，那么找到罪魁祸首是比较容易的事情：只需执行git blame。该命令会显示出文件中每一行的作者，提交hash则会找出该行的上一次修改，还能看到提交的时间戳：

$ git blame

　　当然，Git命令是非常多的，除了上面介绍的12个重要命令外，相信各位InfoQ读者在日常工作过程中也有自己偏爱且好用的一些命令，不妨以评论的形式与其他读者一同分享。