Git - Kurzanleitung

Versionskontrollsystem

Version Control System (VCS) ist eine Software, die Softwareentwicklern hilft, zusammenzuarbeiten und einen vollständigen Verlauf ihrer Arbeit zu führen.

Nachfolgend sind die Funktionen eines VCS aufgeführt -

• Ermöglicht Entwicklern die gleichzeitige Arbeit.
• Erlaubt nicht, die Änderungen des anderen zu überschreiben.
• Pflegt eine Historie jeder Version.

Im Folgenden sind die Arten von VCS aufgeführt:

• Zentrales Versionskontrollsystem (CVCS).
• Verteiltes / dezentrales Versionskontrollsystem (DVCS).

In diesem Kapitel konzentrieren wir uns nur auf das verteilte Versionskontrollsystem und insbesondere auf Git. Git fällt unter das verteilte Versionskontrollsystem.

Verteiltes Versionskontrollsystem

Das zentrale Versionskontrollsystem (CVCS) verwendet einen zentralen Server zum Speichern aller Dateien und ermöglicht die Zusammenarbeit im Team. Der Hauptnachteil von CVCS ist jedoch sein einzelner Fehlerpunkt, dh der Ausfall des zentralen Servers. Wenn der zentrale Server eine Stunde lang ausfällt, kann während dieser Stunde leider überhaupt niemand zusammenarbeiten. Und selbst im schlimmsten Fall verlieren Sie den gesamten Verlauf des Projekts, wenn die Festplatte des zentralen Servers beschädigt wird und keine ordnungsgemäße Sicherung durchgeführt wurde. Hier kommt das verteilte Versionskontrollsystem (DVCS) ins Spiel.

DVCS-Clients überprüfen nicht nur den neuesten Snapshot des Verzeichnisses, sondern spiegeln auch das Repository vollständig wider. Wenn der Server ausfällt, kann das Repository von einem beliebigen Client zurück auf den Server kopiert werden, um es wiederherzustellen. Jeder Checkout ist eine vollständige Sicherung des Repositorys. Git ist nicht auf den zentralen Server angewiesen. Deshalb können Sie viele Vorgänge ausführen, wenn Sie offline sind. Sie können Änderungen festschreiben, Zweige erstellen, Protokolle anzeigen und andere Vorgänge ausführen, wenn Sie offline sind. Sie benötigen nur eine Netzwerkverbindung, um Ihre Änderungen zu veröffentlichen und die neuesten Änderungen zu übernehmen.

Vorteile von Git

Kostenlos und Open Source

Git wird unter der Open Source-Lizenz der GPL veröffentlicht. Es ist frei über das Internet verfügbar. Mit Git können Sie Immobilienprojekte verwalten, ohne einen einzigen Cent zu zahlen. Da es sich um Open Source handelt, können Sie den Quellcode herunterladen und Änderungen entsprechend Ihren Anforderungen vornehmen.

Schnell und klein

Da die meisten Operationen lokal ausgeführt werden, bietet dies einen enormen Geschwindigkeitsvorteil. Git ist nicht auf den zentralen Server angewiesen. Aus diesem Grund muss nicht bei jedem Vorgang mit dem Remote-Server interagiert werden. Der Kern von Git ist in C geschrieben, wodurch Laufzeit-Overheads vermieden werden, die mit anderen Hochsprachen verbunden sind. Obwohl Git das gesamte Repository spiegelt, ist die Größe der Daten auf der Clientseite gering. Dies zeigt die Effizienz von Git beim Komprimieren und Speichern von Daten auf der Clientseite.

Implizite Sicherung

Die Wahrscheinlichkeit eines Datenverlusts ist sehr gering, wenn mehrere Kopien vorhanden sind. Auf jeder Clientseite vorhandene Daten spiegeln das Repository wider und können daher im Falle eines Absturzes oder einer Beschädigung der Festplatte verwendet werden.

Sicherheit

Git verwendet eine allgemeine kryptografische Hash-Funktion namens Secure Hash Function (SHA1), um Objekte in seiner Datenbank zu benennen und zu identifizieren. Jede Datei und jedes Commit wird beim Auschecken von der Prüfsumme überprüft und abgerufen. Dies bedeutet, dass es unmöglich ist, Datei, Datum und Festschreibungsnachricht sowie andere Daten aus der Git-Datenbank zu ändern, ohne Git zu kennen.

Keine Notwendigkeit für leistungsstarke Hardware

Im Fall von CVCS muss der zentrale Server leistungsfähig genug sein, um Anforderungen des gesamten Teams zu erfüllen. Für kleinere Teams ist dies kein Problem, aber mit zunehmender Teamgröße können die Hardwareeinschränkungen des Servers einen Leistungsengpass darstellen. Im Falle von DVCS interagieren Entwickler nicht mit dem Server, es sei denn, sie müssen Änderungen pushen oder ziehen. Das ganze schwere Heben geschieht auf der Clientseite, so dass die Serverhardware in der Tat sehr einfach sein kann.

Einfachere Verzweigung

CVCS verwendet einen billigen Kopiermechanismus. Wenn wir einen neuen Zweig erstellen, werden alle Codes in den neuen Zweig kopiert, was zeitaufwändig und nicht effizient ist. Das Löschen und Zusammenführen von Zweigen in CVCS ist kompliziert und zeitaufwändig. Die Filialverwaltung mit Git ist jedoch sehr einfach. Das Erstellen, Löschen und Zusammenführen von Zweigen dauert nur wenige Sekunden.

DVCS-Terminologien

Lokales Repository

Jedes VCS-Tool bietet einen privaten Arbeitsplatz als Arbeitskopie. Entwickler nehmen Änderungen an ihrem privaten Arbeitsplatz vor und nach dem Festschreiben werden diese Änderungen Teil des Repositorys. Git geht noch einen Schritt weiter und stellt ihnen eine private Kopie des gesamten Repositorys zur Verfügung. Benutzer können mit diesem Repository viele Vorgänge ausführen, z. B. Datei hinzufügen, Datei entfernen, Datei umbenennen, Datei verschieben, Änderungen festschreiben und vieles mehr.

Arbeitsverzeichnis und Staging-Bereich oder Index

Das Arbeitsverzeichnis ist der Ort, an dem Dateien ausgecheckt werden. In anderen CVCS nehmen Entwickler im Allgemeinen Änderungen vor und übertragen ihre Änderungen direkt in das Repository. Aber Git verwendet eine andere Strategie. Git verfolgt nicht jede geänderte Datei. Immer wenn Sie eine Operation festschreiben, sucht Git nach den im Staging-Bereich vorhandenen Dateien. Nur die im Staging-Bereich vorhandenen Dateien werden für das Festschreiben berücksichtigt und nicht alle geänderten Dateien.

Lassen Sie uns den grundlegenden Workflow von Git sehen.

Step 1 - Sie ändern eine Datei aus dem Arbeitsverzeichnis.

Step 2 - Sie fügen diese Dateien dem Staging-Bereich hinzu.

Step 3- Sie führen eine Festschreibungsoperation aus, bei der die Dateien aus dem Staging-Bereich verschoben werden. Nach dem Push-Vorgang werden die Änderungen dauerhaft im Git-Repository gespeichert.

Angenommen, Sie haben zwei Dateien geändert, nämlich "sort.c" und "search.c", und Sie möchten zwei verschiedene Commits für jede Operation. Sie können eine Datei im Staging-Bereich hinzufügen und festschreiben. Wiederholen Sie nach dem ersten Festschreiben das gleiche Verfahren für eine andere Datei.

# First commit
[bash]$ git add sort.c # adds file to the staging area [bash]$ git commit –m “Added sort operation”

# Second commit
[bash]$ git add search.c # adds file to the staging area [bash]$ git commit –m “Added search operation”

Blobs

Blob steht für Binary Large Object. Jede Version einer Datei wird durch einen Blob dargestellt. Ein Blob enthält die Dateidaten, enthält jedoch keine Metadaten zur Datei. Es ist eine Binärdatei und wird in der Git-Datenbank als SHA1-Hash dieser Datei bezeichnet. In Git werden Dateien nicht mit Namen adressiert. Alles ist inhaltlich adressiert.

Bäume

Baum ist ein Objekt, das ein Verzeichnis darstellt. Es enthält Blobs sowie andere Unterverzeichnisse. Ein Baum ist eine Binärdatei, in der Verweise auf Blobs und Bäume gespeichert sind, die auch als bezeichnet werdenSHA1 Hash des Baumobjekts.

Commits

Commit enthält den aktuellen Status des Repositorys. Ein Commit wird auch von benanntSHA1Hash. Sie können ein Festschreibungsobjekt als Knoten der verknüpften Liste betrachten. Jedes Festschreibungsobjekt hat einen Zeiger auf das übergeordnete Festschreibungsobjekt. Von einem bestimmten Commit können Sie zurückgehen, indem Sie auf den übergeordneten Zeiger schauen, um den Verlauf des Commits anzuzeigen. Wenn ein Commit mehrere übergeordnete Commits enthält, wurde dieses bestimmte Commit durch Zusammenführen von zwei Zweigen erstellt.

Geäst

Zweige werden verwendet, um eine weitere Entwicklungslinie zu erstellen. Standardmäßig verfügt Git über einen Hauptzweig, der dem Stamm in Subversion entspricht. Normalerweise wird ein Zweig erstellt, um an einer neuen Funktion zu arbeiten. Sobald das Feature abgeschlossen ist, wird es wieder mit dem Hauptzweig zusammengeführt und wir löschen den Zweig. Jeder Zweig wird von HEAD referenziert, was auf das letzte Commit in dem Zweig verweist. Wann immer Sie ein Commit durchführen, wird HEAD mit dem neuesten Commit aktualisiert.

Stichworte

Das Tag weist einer bestimmten Version im Repository einen aussagekräftigen Namen zu. Tags sind Zweigen sehr ähnlich, aber der Unterschied besteht darin, dass Tags unveränderlich sind. Es bedeutet, dass Tag ein Zweig ist, den niemand ändern möchte. Sobald ein Tag für ein bestimmtes Commit erstellt wurde, wird es nicht aktualisiert, selbst wenn Sie ein neues Commit erstellen. Normalerweise erstellen Entwickler Tags für Produktversionen.

Klon

Durch das Klonen wird die Instanz des Repositorys erstellt. Der Klonvorgang checkt nicht nur die Arbeitskopie aus, sondern spiegelt auch das gesamte Repository wider. Benutzer können mit diesem lokalen Repository viele Vorgänge ausführen. Das Netzwerk wird nur dann eingebunden, wenn die Repository-Instanzen synchronisiert werden.

ziehen

Der Pull-Vorgang kopiert die Änderungen von einer Remote-Repository-Instanz in eine lokale. Die Pull-Operation wird für die Synchronisation zwischen zwei Repository-Instanzen verwendet. Dies entspricht dem Aktualisierungsvorgang in Subversion.

drücken

Der Push-Vorgang kopiert Änderungen von einer lokalen Repository-Instanz auf eine Remote-Instanz. Dies wird verwendet, um die Änderungen dauerhaft im Git-Repository zu speichern. Dies entspricht der Festschreibungsoperation in Subversion.

KOPF

HEAD ist ein Zeiger, der immer auf das letzte Commit in der Verzweigung verweist. Wann immer Sie ein Commit durchführen, wird HEAD mit dem neuesten Commit aktualisiert. Die Köpfe der Zweige sind in gespeichert.git/refs/heads/ Verzeichnis.

[CentOS]$ ls -1 .git/refs/heads/ master [CentOS]$ cat .git/refs/heads/master
570837e7d58fa4bccd86cb575d884502188b0c49

Revision

Die Revision repräsentiert die Version des Quellcodes. Revisionen in Git werden durch Commits dargestellt. Diese Commits sind gekennzeichnet durchSHA1 sichere Hashes.

URL

Die URL repräsentiert den Speicherort des Git-Repositorys. Die Git-URL wird in der Konfigurationsdatei gespeichert.

[tom@CentOS tom_repo]$ pwd /home/tom/tom_repo [tom@CentOS tom_repo]$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = [email protected]:project.git
fetch = +refs/heads/*:refs/remotes/origin/*

Bevor Sie Git verwenden können, müssen Sie einige grundlegende Konfigurationsänderungen installieren und vornehmen. Im Folgenden finden Sie die Schritte zum Installieren des Git-Clients unter Ubuntu und Centos Linux.

Installation von Git Client

Wenn Sie die Debian-Basis-GNU / Linux-Distribution verwenden, dann apt-get Befehl wird das Notwendige tun.

[ubuntu ~]$ sudo apt-get install git-core [sudo] password for ubuntu: [ubuntu ~]$ git --version
git version 1.8.1.2

Und wenn Sie eine RPM-basierte GNU / Linux-Distribution verwenden, verwenden Sie yum Befehl wie angegeben.

[CentOS ~]$
su -
Password:

[CentOS ~]# yum -y install git-core

[CentOS ~]# git --version
git version 1.7.1

Passen Sie die Git-Umgebung an

Git bietet das Git-Konfigurationstool, mit dem Sie Konfigurationsvariablen festlegen können. Git speichert alle globalen Konfigurationen in.gitconfigDatei, die sich in Ihrem Home-Verzeichnis befindet. Um diese Konfigurationswerte als global festzulegen, fügen Sie Folgendes hinzu:--global Option, und wenn Sie weglassen --global Option, dann sind Ihre Konfigurationen spezifisch für das aktuelle Git-Repository.

Sie können auch eine systemweite Konfiguration einrichten. Git speichert diese Werte in der/etc/gitconfigDatei, die die Konfiguration für jeden Benutzer und jedes Repository auf dem System enthält. Um diese Werte festzulegen, müssen Sie über die Root-Rechte verfügen und die verwenden--system Möglichkeit.

Wenn der obige Code kompiliert und ausgeführt wird, ergibt sich das folgende Ergebnis:

Benutzername einstellen

Diese Informationen werden von Git für jedes Commit verwendet.

[jerry@CentOS project]$ git config --global user.name "Jerry Mouse"

E-Mail-ID einstellen

Diese Informationen werden von Git für jedes Commit verwendet.

[jerry@CentOS project]$ git config --global user.email "[email protected]"

Vermeiden Sie Zusammenführungs-Commits zum Ziehen

Sie ziehen die neuesten Änderungen aus einem Remote-Repository. Wenn diese Änderungen unterschiedlich sind, erstellt Git standardmäßig Zusammenführungs-Commits. Wir können dies durch folgende Einstellungen vermeiden.

jerry@CentOS project]$ git config --global branch.autosetuprebase always

Farbhervorhebung

Die folgenden Befehle aktivieren die Farbhervorhebung für Git in der Konsole.

[jerry@CentOS project]$ git config --global color.ui true [jerry@CentOS project]$ git config --global color.status auto

[jerry@CentOS project]$ git config --global color.branch auto

Standardeditor einstellen

Standardmäßig verwendet Git den Systemstandardeditor, der aus der Umgebungsvariablen VISUAL oder EDITOR stammt. Wir können eine andere mit git config konfigurieren.

[jerry@CentOS project]$ git config --global core.editor vim

Festlegen des Standard-Zusammenführungswerkzeugs

Git bietet kein Standard-Merge-Tool zum Integrieren widersprüchlicher Änderungen in Ihren Arbeitsbaum. Wir können das Standard-Zusammenführungswerkzeug festlegen, indem wir die folgenden Einstellungen aktivieren.

[jerry@CentOS project]$ git config --global merge.tool vimdiff

Auflisten der Git-Einstellungen

Verwenden Sie, um Ihre Git-Einstellungen des lokalen Repositorys zu überprüfen git config –list Befehl wie unten angegeben.

[jerry@CentOS ~]$ git config --list

Der obige Befehl führt zu folgendem Ergebnis.

user.name=Jerry Mouse
[email protected]
push.default=nothing
branch.autosetuprebase=always
color.ui=true
color.status=auto
color.branch=auto
core.editor=vim
merge.tool=vimdiff

In diesem Kapitel werden wir den Lebenszyklus von Git diskutieren. In späteren Kapiteln werden wir die Git-Befehle für jede Operation behandeln.

Der allgemeine Workflow lautet wie folgt:

• Sie klonen das Git-Repository als Arbeitskopie.

• Sie ändern die Arbeitskopie, indem Sie Dateien hinzufügen / bearbeiten.

• Bei Bedarf aktualisieren Sie auch die Arbeitskopie, indem Sie die Änderungen anderer Entwickler übernehmen.

• Sie überprüfen die Änderungen vor dem Festschreiben.

• Sie übernehmen Änderungen. Wenn alles in Ordnung ist, übertragen Sie die Änderungen in das Repository.

• Wenn Sie nach dem Festschreiben feststellen, dass etwas nicht stimmt, korrigieren Sie das letzte Festschreiben und übertragen die Änderungen in das Repository.

Unten sehen Sie die bildliche Darstellung des Arbeitsablaufs.

In diesem Kapitel erfahren Sie, wie Sie ein Remote-Git-Repository erstellen. Von nun an werden wir es als Git Server bezeichnen. Wir benötigen einen Git-Server, um die Zusammenarbeit im Team zu ermöglichen.

Neuen Benutzer erstellen

# add new group
[root@CentOS ~]# groupadd dev

# add new user
[root@CentOS ~]# useradd -G devs -d /home/gituser -m -s /bin/bash gituser

# change password
[root@CentOS ~]# passwd gituser

Der obige Befehl führt zu folgendem Ergebnis.

Changing password for user gituser.
New password:
Retype new password:
passwd: all authentication token updated successfully.

Erstellen Sie ein nacktes Repository

Lassen Sie uns ein neues Repository mithilfe von initialisieren init Befehl gefolgt von --bareMöglichkeit. Es initialisiert das Repository ohne Arbeitsverzeichnis. Konventionell muss das nackte Repository als benannt werden.git.

[gituser@CentOS ~]$ pwd /home/gituser [gituser@CentOS ~]$ mkdir project.git

[gituser@CentOS ~]$ cd project.git/ [gituser@CentOS project.git]$ ls

[gituser@CentOS project.git]$ git --bare init Initialized empty Git repository in /home/gituser-m/project.git/ [gituser@CentOS project.git]$ ls
branches config description HEAD hooks info objects refs

Generieren Sie ein öffentliches / privates RSA-Schlüsselpaar

Lassen Sie uns durch den Prozess der Konfiguration eines Git-Servers gehen. ssh-keygen Das Dienstprogramm generiert ein öffentliches / privates RSA-Schlüsselpaar, das wir für die Benutzerauthentifizierung verwenden.

Öffnen Sie ein Terminal, geben Sie den folgenden Befehl ein und drücken Sie für jeden Eingang die Eingabetaste. Nach erfolgreichem Abschluss wird ein erstellt.ssh Verzeichnis innerhalb des Home-Verzeichnisses.

tom@CentOS ~]$ pwd /home/tom [tom@CentOS ~]$ ssh-keygen

Der obige Befehl führt zu folgendem Ergebnis.

Generating public/private rsa key pair.
Enter file in which to save the key (/home/tom/.ssh/id_rsa): Press Enter Only
Created directory '/home/tom/.ssh'.
Enter passphrase (empty for no passphrase): ---------------> Press Enter Only
Enter same passphrase again: ------------------------------> Press Enter Only
Your identification has been saved in /home/tom/.ssh/id_rsa.
Your public key has been saved in /home/tom/.ssh/id_rsa.pub.
The key fingerprint is:
df:93:8c:a1:b8:b7:67:69:3a:1f:65:e8:0e:e9:25:a1 tom@CentOS
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
|
.
|
| Soo |
| o*B. |
| E = *.= |
| oo==. . |
| ..+Oo
|
+-----------------+

ssh-keygen hat zwei Schlüssel generiert, der erste ist privat (dh id_rsa) und der zweite ist öffentlich (dh id_rsa.pub).

Note: Teilen Sie niemals Ihren PRIVATEN SCHLÜSSEL mit anderen.

Hinzufügen von Schlüsseln zu autorisierten Schlüsseln

Angenommen, zwei Entwickler arbeiten an einem Projekt, nämlich Tom und Jerry. Beide Benutzer haben öffentliche Schlüssel generiert. Lassen Sie uns sehen, wie diese Schlüssel zur Authentifizierung verwendet werden.

Tom fügte seinen öffentlichen Schlüssel mithilfe von dem Server hinzu ssh-copy-id Befehl wie unten angegeben -

[tom@CentOS ~]$ pwd /home/tom [tom@CentOS ~]$ ssh-copy-id -i ~/.ssh/id_rsa.pub [email protected]

Der obige Befehl führt zu folgendem Ergebnis.

[email protected]'s password:
Now try logging into the machine, with "ssh '[email protected]'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

In ähnlicher Weise fügte Jerry seinen öffentlichen Schlüssel mit dem Befehl ssh-copy-id zum Server hinzu.

[jerry@CentOS ~]$ pwd /home/jerry [jerry@CentOS ~]$ ssh-copy-id -i ~/.ssh/id_rsa [email protected]

Der obige Befehl führt zu folgendem Ergebnis.

[email protected]'s password:
Now try logging into the machine, with "ssh '[email protected]'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.

Änderungen in das Repository übertragen

Wir haben ein nacktes Repository auf dem Server erstellt und zwei Benutzern Zugriff gewährt. Von nun an können Tom und Jerry ihre Änderungen in das Repository übertragen, indem sie es als Remote hinzufügen.

Git init Befehl erstellt .git Verzeichnis zum Speichern von Metadaten über das Repository bei jedem Lesen der Konfiguration aus dem .git/config Datei.

Tom erstellt ein neues Verzeichnis, fügt eine README-Datei hinzu und schreibt seine Änderung als erstes Commit fest. Nach dem Festschreiben überprüft er die Festschreibungsnachricht, indem er das ausführtgit log Befehl.

[tom@CentOS ~]$ pwd /home/tom [tom@CentOS ~]$ mkdir tom_repo

[tom@CentOS ~]$ cd tom_repo/ [tom@CentOS tom_repo]$ git init
Initialized empty Git repository in /home/tom/tom_repo/.git/

[tom@CentOS tom_repo]$ echo 'TODO: Add contents for README' > README [tom@CentOS tom_repo]$ git status -s
?? README

[tom@CentOS tom_repo]$ git add . [tom@CentOS tom_repo]$ git status -s
A README

[tom@CentOS tom_repo]$ git commit -m 'Initial commit'

Der obige Befehl führt zu folgendem Ergebnis.

[master (root-commit) 19ae206] Initial commit
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 README

Tom überprüft die Protokollnachricht, indem er den Befehl git log ausführt.

[tom@CentOS tom_repo]$ git log

Der obige Befehl führt zu folgendem Ergebnis.

commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

Tom hat seine Änderungen in das lokale Repository übernommen. Jetzt ist es Zeit, die Änderungen in das Remote-Repository zu übertragen. Zuvor müssen wir das Repository jedoch als Remote hinzufügen. Dies ist eine einmalige Operation. Danach kann er die Änderungen sicher in das Remote-Repository übertragen.

Note- Standardmäßig pusht Git nur auf übereinstimmende Zweige: Für jeden Zweig, der auf der lokalen Seite vorhanden ist, wird die entfernte Seite aktualisiert, wenn dort bereits ein Zweig mit demselben Namen vorhanden ist. In unseren Tutorials werden jedes Mal Änderungen an derorigin master Zweigstelle, verwenden Sie den entsprechenden Zweigstellennamen entsprechend Ihrer Anforderung.

[tom@CentOS tom_repo]$ git remote add origin [email protected]:project.git [tom@CentOS tom_repo]$ git push origin master

Der obige Befehl führt zu folgendem Ergebnis.

Counting objects: 3, done.
Writing objects: 100% (3/3), 242 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
* [new branch]
master −> master

Jetzt werden die Änderungen erfolgreich in das Remote-Repository übernommen.

Wir haben ein nacktes Repository auf dem Git-Server und Tom hat auch seine erste Version gepusht. Jetzt kann Jerry seine Änderungen anzeigen. Der Klonvorgang erstellt eine Instanz des Remote-Repositorys.

Jerry erstellt ein neues Verzeichnis in seinem Home-Verzeichnis und führt den Klonvorgang aus.

[jerry@CentOS ~]$ mkdir jerry_repo [jerry@CentOS ~]$ cd jerry_repo/

[jerry@CentOS jerry_repo]$ git clone [email protected]:project.git

Der obige Befehl führt zu folgendem Ergebnis.

Initialized empty Git repository in /home/jerry/jerry_repo/project/.git/
remote: Counting objects: 3, done.
Receiving objects: 100% (3/3), 241 bytes, done.
remote: Total 3 (delta 0), reused 0 (delta 0)

Jerry ändert das Verzeichnis in ein neues lokales Repository und listet dessen Verzeichnisinhalt auf.

[jerry@CentOS jerry_repo]$ cd project/

[jerry@CentOS jerry_repo]$ ls
README

Jerry klont das Repository und beschließt, grundlegende Zeichenfolgenoperationen zu implementieren. Also erstellt er die Datei string.c. Nach dem Hinzufügen des Inhalts sieht string.c wie folgt aus:

#include <stdio.h>

int my_strlen(char *s)
{
   char *p = s;

   while (*p)
      ++p;

   return (p - s);
}

int main(void)
{
   int i;
   char *s[] = 
   {
      "Git tutorials",
      "Tutorials Point"
   };

   for (i = 0; i < 2; ++i)
      
   printf("string lenght of %s = %d\n", s[i], my_strlen(s[i]));

   return 0;
}

Er hat seinen Code kompiliert und getestet und alles funktioniert gut. Jetzt kann er diese Änderungen sicher zum Repository hinzufügen.

Git add operation fügt dem Staging-Bereich eine Datei hinzu.

[jerry@CentOS project]$ git status -s
?? string
?? string.c

[jerry@CentOS project]$ git add string.c

Git zeigt ein Fragezeichen vor den Dateinamen. Offensichtlich sind diese Dateien kein Teil von Git, und deshalb weiß Git nicht, was er mit diesen Dateien tun soll. Aus diesem Grund zeigt Git vor Dateinamen ein Fragezeichen an.

Jerry hat die Datei zum Stash-Bereich hinzugefügt. Der Befehl git status zeigt die im Staging-Bereich vorhandenen Dateien an.

[jerry@CentOS project]$ git status -s
A string.c
?? string

Um die Änderungen festzuschreiben, verwendete er den Befehl git commit gefolgt von der Option –m. Wenn wir die Option –m weglassen. Git öffnet einen Texteditor, in den wir eine mehrzeilige Festschreibungsnachricht schreiben können.

[jerry@CentOS project]$ git commit -m 'Implemented my_strlen function'

Der obige Befehl führt zu folgendem Ergebnis:

[master cbe1249] Implemented my_strlen function
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 string.c

Nach dem Festschreiben zum Anzeigen der Protokolldetails führt er den Befehl git log aus. Es werden die Informationen aller Commits mit ihrer Commit-ID, dem Commit-Autor, dem Commit-Datum und angezeigtSHA-1 Hash von Commit.

[jerry@CentOS project]$ git log

Der obige Befehl führt zu folgendem Ergebnis:

commit cbe1249b140dad24b2c35b15cc7e26a6f02d2277
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Implemented my_strlen function


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

Nachdem Jerry die Festschreibungsdetails angezeigt hat, stellt er fest, dass die Zeichenfolgenlänge nicht negativ sein kann. Deshalb beschließt er, den Rückgabetyp der Funktion my_strlen zu ändern.

Jerry benutzt die git log Befehl zum Anzeigen von Protokolldetails.

[jerry@CentOS project]$ git log

Der obige Befehl führt zu folgendem Ergebnis.

commit cbe1249b140dad24b2c35b15cc7e26a6f02d2277
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Implemented my_strlen function

Jerry benutzt die git showBefehl zum Anzeigen der Festschreibungsdetails. Der Befehl git show dauertSHA-1 Commit-ID als Parameter.

[jerry@CentOS project]$ git show cbe1249b140dad24b2c35b15cc7e26a6f02d2277

Der obige Befehl führt zu folgendem Ergebnis:

commit cbe1249b140dad24b2c35b15cc7e26a6f02d2277
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Implemented my_strlen function


diff --git a/string.c b/string.c
new file mode 100644
index 0000000..187afb9
--- /dev/null
+++ b/string.c
@@ -0,0 +1,24 @@
+#include <stdio.h>
+
+int my_strlen(char *s)
+{
   +
   char *p = s;
   +
   +
   while (*p)
   + ++p;
   + return (p -s );
   +
}
+

Er ändert den Rückgabetyp der Funktion von int in size_t. Nachdem er den Code getestet hat, überprüft er seine Änderungen, indem er das ausführtgit diff Befehl.

[jerry@CentOS project]$ git diff

Der obige Befehl führt zu folgendem Ergebnis:

diff --git a/string.c b/string.c
index 187afb9..7da2992 100644
--- a/string.c
+++ b/string.c
@@ -1,6 +1,6 @@
#include <stdio.h>

-int my_strlen(char *s)
+size_t my_strlen(char *s)
{
   char *p = s;
   @@ -18,7 +18,7 @@ int main(void)
};
for (i = 0; i < 2; ++i)
{
   - printf("string lenght of %s = %d\n", s[i], my_strlen(s[i]));
   + printf("string lenght of %s = %lu\n", s[i], my_strlen(s[i]));
   return 0;
}

Git Diff zeigt '+' Zeichen vor Zeilen, die neu hinzugefügt werden und '−' für gelöschte Zeilen.

Jerry hat die Änderungen bereits festgeschrieben und möchte sein letztes Festschreiben korrigieren. In diesem Fall,git amendOperation wird helfen. Die Änderungsoperation ändert das letzte Commit einschließlich Ihrer Commit-Nachricht. Es wird eine neue Festschreibungs-ID erstellt.

Vor dem Ändern des Vorgangs überprüft er das Festschreibungsprotokoll.

[jerry@CentOS project]$ git log

Der obige Befehl führt zu folgendem Ergebnis.

commit cbe1249b140dad24b2c35b15cc7e26a6f02d2277
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Implemented my_strlen function


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

Jerry schreibt die neuen Änderungen mit - Änderungsvorgang fest und zeigt das Festschreibungsprotokoll an.

[jerry@CentOS project]$ git status -s M string.c ?? string [jerry@CentOS project]$ git add string.c

[jerry@CentOS project]$ git status -s M string.c ?? string [jerry@CentOS project]$ git commit --amend -m 'Changed return type of my_strlen to size_t'
[master d1e19d3] Changed return type of my_strlen to size_t
1 files changed, 24 insertions(+), 0 deletions(-)
create mode 100644 string.c

Jetzt zeigt das Git-Protokoll eine neue Festschreibungsnachricht mit einer neuen Festschreibungs-ID an.

[jerry@CentOS project]$ git log

Der obige Befehl führt zu folgendem Ergebnis.

commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

Jerry hat sein letztes Commit mithilfe der Änderungsoperation geändert und ist bereit, die Änderungen voranzutreiben. Die Push-Operation speichert Daten dauerhaft im Git-Repository. Nach einer erfolgreichen Push-Operation können andere Entwickler Jerrys Änderungen sehen.

Er führt den Befehl git log aus, um die Festschreibungsdetails anzuzeigen.

[jerry@CentOS project]$ git log

Der obige Befehl führt zu folgendem Ergebnis:

commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t

Vor der Push-Operation möchte er seine Änderungen überprüfen, also verwendet er die git show Befehl, seine Änderungen zu überprüfen.

[jerry@CentOS project]$ git show d1e19d316224cddc437e3ed34ec3c931ad803958

Der obige Befehl führt zu folgendem Ergebnis:

commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t

diff --git a/string.c b/string.c
new file mode 100644
index 0000000..7da2992
--- /dev/null
+++ b/string.c
@@ -0,0 +1,24 @@
+#include <stdio.h>
+
+size_t my_strlen(char *s)
+
{
   +
   char *p = s;
   +
   +
   while (*p)
   + ++p;
   + return (p -s );
   +
}
+
+int main(void)
+
{
   + int i;
   + char *s[] = 
   {
      + "Git tutorials",
      + "Tutorials Point"
      +
   };
   +
   +
   +
   for (i = 0; i < 2; ++i)
   printf("string lenght of %s = %lu\n", s[i], my_strlen(s[i]));
   +
   +
   return 0;
   +
}

Jerry ist mit seinen Änderungen zufrieden und bereit, seine Änderungen voranzutreiben.

[jerry@CentOS project]$ git push origin master

Der obige Befehl führt zu folgendem Ergebnis:

Counting objects: 4, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 517 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
19ae206..d1e19d3 master −> master

Jerrys Änderungen wurden erfolgreich in das Repository übertragen. Jetzt können andere Entwickler seine Änderungen anzeigen, indem sie einen Klon- oder Aktualisierungsvorgang ausführen.

Vorhandene Funktion ändern

Tom führt die Klonoperation aus und findet eine neue Datei string.c. Er möchte wissen, wer diese Datei zum Repository hinzugefügt hat und zu welchem ​​Zweck, also führt er die ausgit log Befehl.

[tom@CentOS ~]$ git clone [email protected]:project.git

Der obige Befehl führt zu folgendem Ergebnis:

Initialized empty Git repository in /home/tom/project/.git/
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (4/4), done.
Receiving objects: 100% (6/6), 726 bytes, done.
remote: Total 6 (delta 0), reused 0 (delta 0)

Durch das Klonen wird ein neues Verzeichnis im aktuellen Arbeitsverzeichnis erstellt. Er ändert das Verzeichnis in ein neu erstelltes Verzeichnis und führt das ausgit log Befehl.

[tom@CentOS ~]$ cd project/

[tom@CentOS project]$ git log

Der obige Befehl führt zu folgendem Ergebnis:

commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

Nachdem er das Protokoll beobachtet hat, stellt er fest, dass die Datei string.c von Jerry hinzugefügt wurde, um grundlegende Zeichenfolgenoperationen zu implementieren. Er ist neugierig auf Jerrys Code. Also öffnet er string.c im Texteditor und findet sofort einen Fehler. In der Funktion my_strlen verwendet Jerry keinen konstanten Zeiger. Also beschließt er, Jerrys Code zu ändern. Nach der Änderung sieht der Code wie folgt aus:

[tom@CentOS project]$ git diff

Der obige Befehl führt zu folgendem Ergebnis:

diff --git a/string.c b/string.c
index 7da2992..32489eb 100644
--- a/string.c
+++ b/string.c
@@ -1,8 +1,8 @@
#include <stdio.h>
-size_t my_strlen(char *s)
+size_t my_strlen(const char *s)
{
   - char *p = s;
   + const char *p = s;
   while (*p)
   ++p;
}

Nach dem Testen legt er sein Wechselgeld fest.

[tom@CentOS project]$ git status -s M string.c ?? string [tom@CentOS project]$ git add string.c

[tom@CentOS project]$ git commit -m 'Changed char pointer to const char pointer' [master cea2c00] Changed char pointer to const char pointer 1 files changed, 2 insertions(+), 2 deletions(-) [tom@CentOS project]$ git log

Der obige Befehl führt zu folgendem Ergebnis:

commit cea2c000f53ba99508c5959e3e12fff493b
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 08:32:07 2013 +0530

Changed char pointer to const char pointer


commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530
Initial commit

Tom verwendet den Befehl git push, um seine Änderungen zu übertragen.

[tom@CentOS project]$ git push origin master

Der obige Befehl führt zu folgendem Ergebnis:

Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 336 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
d1e19d3..cea2c00 master −> master

Neue Funktion hinzufügen

In der Zwischenzeit beschließt Jerry, umzusetzen string compareFunktionalität. Also modifiziert er string.c. Nach der Änderung sieht die Datei wie folgt aus:

[jerry@CentOS project]$ git diff

Der obige Befehl führt zu folgendem Ergebnis:

index 7da2992..bc864ed 100644
--- a/string.c
+++ b/string.c
30Git Tutorials
@@ -9,9 +9,20 @@ size_t my_strlen(char *s)
return (p -s );
}
+char *my_strcpy(char *t, char *s)
+
{
   +
   char *p = t;
   +
   + while (*t++ = *s++)
   + ;
   +
   +
   return p;
   +
}
+
int main(void)
{
   int i; 
   +
   char p1[32];
   char *s[] = 
   {
      "Git tutorials",
      "Tutorials Point"
      @@ -20,5 +31,7 @@ int main(void)
      for (i = 0; i < 2; ++i)
      printf("string lenght of %s = %lu\n", s[i], my_strlen(s[i]));
      +
      printf("%s\n", my_strcpy(p1, "Hello, World !!!"));
      +
      return 0;
   }
}

Nach dem Testen ist er bereit, sein Wechselgeld zu pushen.

[jerry@CentOS project]$ git status -s M string.c ?? string [jerry@CentOS project]$ git add string.c

[jerry@CentOS project]$ git commit -m "Added my_strcpy function"
[master e944e5a] Added my_strcpy function
1 files changed, 13 insertions(+), 0 deletions(-)

Vor dem Push-Vorgang überprüft er das Festschreiben durch Anzeigen von Protokollnachrichten.

[jerry@CentOS project]$ git log

Der obige Befehl führt zu folgendem Ergebnis:

commit e944e5aab74b26e7447d3281b225309e4e59efcd
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:41:42 2013 +0530

Added my_strcpy function


commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530

Initial commit

Jerry ist mit den Änderungen zufrieden und möchte seine Änderungen vorantreiben.

[jerry@CentOS project]$ git push origin master

Der obige Befehl führt zu folgendem Ergebnis:

To [email protected]:project.git
! [rejected]
master −> master (non-fast-forward)
error: failed to push some refs to '[email protected]:project.git'
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'Note about
fast-forwards' section of 'git push --help' for details.

Aber Git erlaubt Jerry nicht, seine Änderungen voranzutreiben. Weil Git festgestellt hat, dass das Remote-Repository und das lokale Repository von Jerry nicht synchron sind. Dadurch kann er die Geschichte des Projekts verlieren. Um dieses Durcheinander zu vermeiden, hat Git diesen Vorgang fehlgeschlagen. Jetzt muss Jerry zuerst das lokale Repository aktualisieren und kann erst danach seine eigenen Änderungen vornehmen.

Neueste Änderungen abrufen

Jerry führt den Befehl git pull aus, um sein lokales Repository mit dem Remote-Repository zu synchronisieren.

[jerry@CentOS project]$ git pull

Der obige Befehl führt zu folgendem Ergebnis:

remote: Counting objects: 5, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From git.server.com:project
d1e19d3..cea2c00 master −> origin/master
First, rewinding head to replay your work on top of it...
Applying: Added my_strcpy function

Nach dem Pull-Vorgang überprüft Jerry die Protokollnachrichten und findet die Details von Toms Commit mit Commit-ID cea2c000f53ba99508c5959e3e12fff493ba6f69

[jerry@CentOS project]$ git log

Der obige Befehl führt zu folgendem Ergebnis:

commit e86f0621c2a3f68190bba633a9fe6c57c94f8e4f
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:41:42 2013 +0530

Added my_strcpy function


commit cea2c000f53ba99508c5959e3e12fff493ba6f69
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 08:32:07 2013 +0530

Changed char pointer to const char pointer


commit d1e19d316224cddc437e3ed34ec3c931ad803958
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 08:05:26 2013 +0530

Changed return type of my_strlen to size_t


commit 19ae20683fc460db7d127cf201a1429523b0e319
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 07:32:56 2013 +0530
Initial commit

Jetzt ist Jerrys lokales Repository vollständig mit dem Remote-Repository synchronisiert. So kann er seine Änderungen sicher vorantreiben.

[jerry@CentOS project]$ git push origin master

Der obige Befehl führt zu folgendem Ergebnis:

Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 455 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
cea2c00..e86f062 master −> master

Angenommen, Sie implementieren eine neue Funktion für Ihr Produkt. Ihr Code ist in Bearbeitung und plötzlich kommt eine Kundeneskalation. Aus diesem Grund müssen Sie Ihre neue Funktionsarbeit einige Stunden lang beiseite lassen. Sie können Ihren Teilcode nicht festschreiben und Ihre Änderungen auch nicht wegwerfen. Sie benötigen also temporären Speicherplatz, in dem Sie Ihre Teiländerungen speichern und später festschreiben können.

In Git übernimmt der Stash-Vorgang Ihre geänderten nachverfolgten Dateien, führt Änderungen durch und speichert sie auf einem Stapel nicht abgeschlossener Änderungen, die Sie jederzeit erneut anwenden können.

[jerry@CentOS project]$ git status -s
M string.c
?? string

Jetzt möchten Sie die Filialen wechseln, um die Kunden zu eskalieren, aber Sie möchten nicht festlegen, woran Sie noch gearbeitet haben. Sie werden also die Änderungen aufbewahren. Führen Sie die Taste aus, um einen neuen Stash auf Ihren Stack zu verschiebengit stash Befehl.

[jerry@CentOS project]$ git stash
Saved working directory and index state WIP on master: e86f062 Added my_strcpy function
HEAD is now at e86f062 Added my_strcpy function

Jetzt ist Ihr Arbeitsverzeichnis sauber und alle Änderungen werden auf einem Stapel gespeichert. Lassen Sie es uns mit dem überprüfengit status Befehl.

[jerry@CentOS project]$ git status -s
?? string

Jetzt können Sie den Zweig sicher wechseln und woanders arbeiten. Wir können eine Liste der versteckten Änderungen anzeigen, indem wir das verwendengit stash list Befehl.

[jerry@CentOS project]$ git stash list
stash@{0}: WIP on master: e86f062 Added my_strcpy function

Angenommen, Sie haben die Kundeneskalation behoben und sind wieder bei Ihrer neuen Funktion, um nach Ihrem halbfertigen Code zu suchen. Führen Sie einfach die aus git stash pop Befehl, um die Änderungen vom Stapel zu entfernen und im aktuellen Arbeitsverzeichnis abzulegen.

[jerry@CentOS project]$ git status -s ?? string [jerry@CentOS project]$ git stash pop

Der obige Befehl führt zu folgendem Ergebnis:

# On branch master
# Changed but not updated:
# (use "git add ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
#
modified: string.c
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
#
string
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (36f79dfedae4ac20e2e8558830154bd6315e72d4)

[jerry@CentOS project]$ git status -s
M string.c
?? string

Wie der Name schon sagt, verschiebt der Verschiebevorgang ein Verzeichnis oder eine Datei von einem Speicherort an einen anderen. Tom beschließt, den Quellcode zu verschiebensrcVerzeichnis. Die geänderte Verzeichnisstruktur sieht wie folgt aus:

[tom@CentOS project]$ pwd
/home/tom/project

[tom@CentOS project]$ ls README string string.c [tom@CentOS project]$ mkdir src

[tom@CentOS project]$ git mv string.c src/ [tom@CentOS project]$ git status -s
R string.c −> src/string.c
?? string

Um diese Änderungen dauerhaft zu machen, müssen wir die geänderte Verzeichnisstruktur in das Remote-Repository verschieben, damit andere Entwickler dies sehen können.

[tom@CentOS project]$ git commit -m "Modified directory structure" [master 7d9ea97] Modified directory structure 1 files changed, 0 insertions(+), 0 deletions(-) rename string.c => src/string.c (100%) [tom@CentOS project]$ git push origin master
Counting objects: 4, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 320 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
e86f062..7d9ea97 master −> master

In Jerrys lokalem Repository wird vor dem Pull-Vorgang die alte Verzeichnisstruktur angezeigt.

[jerry@CentOS project]$ pwd /home/jerry/jerry_repo/project [jerry@CentOS project]$ ls
README string string.c

Nach dem Pull-Vorgang wird die Verzeichnisstruktur jedoch aktualisiert. Jetzt kann Jerry das sehensrc Verzeichnis und die in diesem Verzeichnis vorhandene Datei.

[jerry@CentOS project]$ git pull remote: Counting objects: 4, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From git.server.com:project e86f062..7d9ea97 master −> origin/master First, rewinding head to replay your work on top of it... Fast-forwarded master to 7d9ea97683da90bcdb87c28ec9b4f64160673c8a. [jerry@CentOS project]$ ls
README src string

[jerry@CentOS project]$ ls src/
string.c

Bis jetzt verwendeten sowohl Tom als auch Jerry manuelle Befehle, um ihr Projekt zu kompilieren. Jetzt beschließt Jerry, Makefile für sein Projekt zu erstellen und der Datei "string.c" einen richtigen Namen zu geben.

[jerry@CentOS project]$ pwd
/home/jerry/jerry_repo/project

[jerry@CentOS project]$ ls README src [jerry@CentOS project]$ cd src/

[jerry@CentOS src]$ git add Makefile [jerry@CentOS src]$ git mv string.c string_operations.c

[jerry@CentOS src]$ git status -s
A Makefile
R string.c −> string_operations.c

Git zeigt R vor dem Dateinamen, um anzuzeigen, dass die Datei umbenannt wurde.

Für die Festschreibungsoperation verwendete Jerry -a Flag, wodurch git commit die geänderten Dateien automatisch erkennt.

[jerry@CentOS src]$ git commit -a -m 'Added Makefile and renamed strings.c to
string_operations.c '

[master 94f7b26] Added Makefile and renamed strings.c to string_operations.c
1 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 src/Makefile
rename src/{string.c => string_operations.c} (100%)

Nach dem Festschreiben überträgt er seine Änderungen in das Repository.

[jerry@CentOS src]$ git push origin master

Der obige Befehl führt zu folgendem Ergebnis:

Counting objects: 6, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 396 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
7d9ea97..94f7b26 master −> master

Jetzt können andere Entwickler diese Änderungen anzeigen, indem sie ihr lokales Repository aktualisieren.

Tom aktualisiert sein lokales Repository und findet die kompilierte Binärdatei in der srcVerzeichnis. Nachdem er die Commit-Nachricht angezeigt hat, stellt er fest, dass die kompilierte Binärdatei von Jerry hinzugefügt wurde.

[tom@CentOS src]$ pwd
/home/tom/project/src

[tom@CentOS src]$ ls Makefile string_operations string_operations.c [tom@CentOS src]$ file string_operations
string_operations: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses
shared libs), for GNU/Linux 2.6.18, not stripped

[tom@CentOS src]$ git log
commit 29af9d45947dc044e33d69b9141d8d2dad37cc62
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 10:16:25 2013 +0530

Added compiled binary

VCS wird verwendet, um nur den Quellcode und keine ausführbaren Binärdateien zu speichern. Also beschließt Tom, diese Datei aus dem Repository zu entfernen. Für den weiteren Betrieb nutzt er diegit rm Befehl.

[tom@CentOS src]$ ls
Makefile string_operations string_operations.c

[tom@CentOS src]$ git rm string_operations rm 'src/string_operations' [tom@CentOS src]$ git commit -a -m "Removed executable binary"

[master 5776472] Removed executable binary
1 files changed, 0 insertions(+), 0 deletions(-)
delete mode 100755 src/string_operations

Nach dem Festschreiben überträgt er seine Änderungen in das Repository.

[tom@CentOS src]$ git push origin master

Der obige Befehl führt zu folgendem Ergebnis.

Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 310 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
29af9d4..5776472 master −> master

Irren ist menschlich. So bietet jedes VCS eine Funktion, um Fehler bis zu einem bestimmten Punkt zu beheben. Git bietet eine Funktion, mit der wir die am lokalen Repository vorgenommenen Änderungen rückgängig machen können.

Angenommen, der Benutzer nimmt versehentlich einige Änderungen an seinem lokalen Repository vor und möchte diese Änderungen dann rückgängig machen. In solchen Fällen ist dierevert Betrieb spielt eine wichtige Rolle.

Nicht festgeschriebene Änderungen rückgängig machen

Nehmen wir an, Jerry ändert versehentlich eine Datei aus seinem lokalen Repository. Aber er möchte seine Änderung rückgängig machen. Um mit dieser Situation umzugehen, können wir die verwendengit checkoutBefehl. Mit diesem Befehl können wir den Inhalt einer Datei zurücksetzen.

[jerry@CentOS src]$ pwd
/home/jerry/jerry_repo/project/src

[jerry@CentOS src]$ git status -s M string_operations.c [jerry@CentOS src]$ git checkout string_operations.c

[jerry@CentOS src]$ git status –s

Weiter können wir die verwenden git checkoutBefehl zum Abrufen einer gelöschten Datei aus dem lokalen Repository. Nehmen wir an, Tom löscht eine Datei aus dem lokalen Repository und wir möchten diese Datei zurück. Wir können dies erreichen, indem wir denselben Befehl verwenden.

[tom@CentOS src]$ pwd
/home/tom/top_repo/project/src

[tom@CentOS src]$ ls -1 Makefile string_operations.c [tom@CentOS src]$ rm string_operations.c

[tom@CentOS src]$ ls -1 Makefile [tom@CentOS src]$ git status -s
D string_operations.c

Git zeigt den Brief Dvor dem Dateinamen. Dies zeigt an, dass die Datei aus dem lokalen Repository gelöscht wurde.

[tom@CentOS src]$ git checkout string_operations.c [tom@CentOS src]$ ls -1
Makefile
string_operations.c

[tom@CentOS src]$ git status -s

Note - Wir können alle diese Operationen vor dem Festschreiben ausführen.

Entfernen Sie Änderungen aus dem Staging-Bereich

Wir haben gesehen, dass beim Ausführen eines Add-Vorgangs die Dateien vom lokalen Repository in den angegebenen Bereich verschoben werden. Wenn ein Benutzer versehentlich eine Datei ändert und sie dem Staging-Bereich hinzufügt, kann er seine Änderungen mithilfe von zurücksetzengit checkout Befehl.

In Git gibt es einen HEAD-Zeiger, der immer auf das letzte Commit zeigt. Wenn Sie eine Änderung aus dem bereitgestellten Bereich rückgängig machen möchten, können Sie den Befehl git checkout verwenden. Mit dem Befehl checkout müssen Sie jedoch einen zusätzlichen Parameter angeben, z. B. den HEAD-Zeiger. Der zusätzliche Commit-Zeigerparameter weist den Befehl git checkout an, den Arbeitsbaum zurückzusetzen und die bereitgestellten Änderungen zu entfernen.

Nehmen wir an, Tom ändert eine Datei aus seinem lokalen Repository. Wenn wir den Status dieser Datei anzeigen, wird angezeigt, dass die Datei geändert, aber nicht zum Staging-Bereich hinzugefügt wurde.

tom@CentOS src]$ pwd
/home/tom/top_repo/project/src
# Unmodified file

[tom@CentOS src]$ git status -s # Modify file and view it’s status. [tom@CentOS src]$ git status -s
M string_operations.c

[tom@CentOS src]$ git add string_operations.c

Der Git-Status zeigt an, dass die Datei im Staging-Bereich vorhanden ist. Setzen Sie sie jetzt mit dem Befehl git checkout zurück und zeigen Sie den Status der zurückgesetzten Datei an.

[tom@CentOS src]$ git checkout HEAD -- string_operations.c

[tom@CentOS src]$ git status -s

Verschieben Sie den HEAD Pointer mit Git Reset

Nachdem Sie einige Änderungen vorgenommen haben, können Sie diese Änderungen entfernen. Der Befehl Git reset wird verwendet, um Änderungen zurückzusetzen oder zurückzusetzen. Wir können drei verschiedene Arten von Rücksetzvorgängen ausführen.

Das folgende Diagramm zeigt die bildliche Darstellung des Git-Reset-Befehls.

Sanft

Jeder Zweig verfügt über einen HEAD-Zeiger, der auf das letzte Commit verweist. Wenn wir den Git-Reset-Befehl mit der Option --soft gefolgt von der Commit-ID verwenden, wird der HEAD-Zeiger nur zurückgesetzt, ohne etwas zu zerstören.

.git/refs/heads/masterDatei speichert die Commit-ID des HEAD-Zeigers. Wir können es mit dem überprüfengit log -1 Befehl.

[jerry@CentOS project]$ cat .git/refs/heads/master
577647211ed44fe2ae479427a0668a4f12ed71a1

Zeigen Sie nun die neueste Festschreibungs-ID an, die mit der obigen Festschreibungs-ID übereinstimmt.

[jerry@CentOS project]$ git log -2

Der obige Befehl führt zu folgendem Ergebnis.

commit 577647211ed44fe2ae479427a0668a4f12ed71a1
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 10:21:20 2013 +0530

Removed executable binary


commit 29af9d45947dc044e33d69b9141d8d2dad37cc62
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 10:16:25 2013 +0530

Added compiled binary

Setzen wir den HEAD-Zeiger zurück.

[jerry@CentOS project]$ git reset --soft HEAD~

Jetzt setzen wir den HEAD-Zeiger nur um eine Position zurück. Lassen Sie uns den Inhalt von überprüfen.git/refs/heads/master file.

[jerry@CentOS project]$ cat .git/refs/heads/master
29af9d45947dc044e33d69b9141d8d2dad37cc62

Die Festschreibungs-ID aus der Datei wurde geändert. Überprüfen Sie sie jetzt, indem Sie Festschreibungsnachrichten anzeigen.

jerry@CentOS project]$ git log -2

Der obige Befehl führt zu folgendem Ergebnis.

commit 29af9d45947dc044e33d69b9141d8d2dad37cc62
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 10:16:25 2013 +0530

Added compiled binary


commit 94f7b26005f856f1a1b733ad438e97a0cd509c1a
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 10:08:01 2013 +0530

Added Makefile and renamed strings.c to string_operations.c

gemischt

Git-Reset mit der Option --mixed setzt die Änderungen aus dem Staging-Bereich zurück, die noch nicht festgeschrieben wurden. Es werden nur die Änderungen aus dem Staging-Bereich zurückgesetzt. Die tatsächlichen Änderungen an der Arbeitskopie der Datei bleiben unberührt. Der Standard-Git-Reset entspricht dem Git-Reset - gemischt.

schwer

Wenn Sie die Option --hard mit dem Befehl Git reset verwenden, wird der Staging-Bereich gelöscht. Dadurch wird der HEAD-Zeiger auf das letzte Commit der spezifischen Commit-ID zurückgesetzt und auch die lokalen Dateiänderungen gelöscht.

Lassen Sie uns die Commit-ID überprüfen.

[jerry@CentOS src]$ pwd /home/jerry/jerry_repo/project/src [jerry@CentOS src]$ git log -1

Der obige Befehl führt zu folgendem Ergebnis.

commit 577647211ed44fe2ae479427a0668a4f12ed71a1
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 10:21:20 2013 +0530

Removed executable binary

Jerry hat eine Datei geändert, indem er am Anfang der Datei einen einzeiligen Kommentar hinzugefügt hat.

[jerry@CentOS src]$ head -2 string_operations.c
/* This line be removed by git reset operation */
#include <stdio.h>

Er überprüfte es mit dem Befehl git status.

[jerry@CentOS src]$ git status -s
M string_operations.c

Jerry fügt die geänderte Datei dem Staging-Bereich hinzu und überprüft sie mit dem Befehl git status.

[jerry@CentOS src]$ git add string_operations.c [jerry@CentOS src]$ git status

Der obige Befehl führt zu folgendem Ergebnis.

# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
#
modified: string_operations.c
#

Der Git-Status zeigt an, dass die Datei im Staging-Bereich vorhanden ist. Setzen Sie nun HEAD mit der Option - hard zurück.

[jerry@CentOS src]$ git reset --hard 577647211ed44fe2ae479427a0668a4f12ed71a1

HEAD is now at 5776472 Removed executable binary

Der Git-Reset-Befehl war erfolgreich, wodurch die Datei aus dem Staging-Bereich zurückgesetzt und alle lokalen Änderungen an der Datei entfernt werden.

[jerry@CentOS src]$ git status -s

Der Git-Status zeigt an, dass die Datei aus dem Staging-Bereich zurückgesetzt wurde.

[jerry@CentOS src]$ head -2 string_operations.c
#include <stdio.h>

Der Befehl head zeigt auch, dass durch das Zurücksetzen auch die lokalen Änderungen entfernt wurden.

Mit der Tag-Operation können Sie einer bestimmten Version im Repository aussagekräftige Namen geben. Angenommen, Tom und Jerry beschließen, ihren Projektcode zu kennzeichnen, damit sie später problemlos darauf zugreifen können.

Tags erstellen

Lassen Sie uns den aktuellen HEAD mit dem markieren git tagBefehl. Tom stellt einen Tag-Namen mit der Option -a und eine Tag-Nachricht mit der Option –m bereit.

tom@CentOS project]$ pwd
/home/tom/top_repo/project

[tom@CentOS project]$ git tag -a 'Release_1_0' -m 'Tagged basic string operation code' HEAD

Wenn Sie ein bestimmtes Commit markieren möchten, verwenden Sie die entsprechende COMMIT-ID anstelle des HEAD-Zeigers. Tom verwendet den folgenden Befehl, um das Tag in das Remote-Repository zu verschieben.

[tom@CentOS project]$ git push origin tag Release_1_0

Der obige Befehl führt zu folgendem Ergebnis:

Counting objects: 1, done.
Writing objects: 100% (1/1), 183 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
* [new tag]
Release_1_0 −> Release_1_0

Tags anzeigen

Tom hat Tags erstellt. Jetzt kann Jerry alle verfügbaren Tags anzeigen, indem er den Befehl Git tag mit der Option –l verwendet.

[jerry@CentOS src]$ pwd /home/jerry/jerry_repo/project/src [jerry@CentOS src]$ git pull
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (1/1), done.
From git.server.com:project
* [new tag]
Release_1_0 −> Release_1_0
Current branch master is up to date.

[jerry@CentOS src]$ git tag -l
Release_1_0

Jerry verwendet den Befehl Git show gefolgt von seinem Tag-Namen, um weitere Details zum Tag anzuzeigen.

[jerry@CentOS src]$ git show Release_1_0

Der obige Befehl führt zu folgendem Ergebnis:

tag Release_1_0
Tagger: Tom Cat <[email protected]>
Date: Wed Sep 11 13:45:54 2013 +0530

Tagged basic string operation code


commit 577647211ed44fe2ae479427a0668a4f12ed71a1
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 10:21:20 2013 +0530

Removed executable binary

diff --git a/src/string_operations b/src/string_operations
deleted file mode 100755
index 654004b..0000000
Binary files a/src/string_operations and /dev/null differ

Tags löschen

Tom verwendet den folgenden Befehl, um Tags sowohl aus dem lokalen als auch aus dem Remote-Repository zu löschen.

[tom@CentOS project]$ git tag Release_1_0 [tom@CentOS project]$ git tag -d Release_1_0
Deleted tag 'Release_1_0' (was 0f81ff4)
# Remove tag from remote repository.

[tom@CentOS project]$ git push origin :Release_1_0
To [email protected]:project.git
- [deleted]
Release_1_0

Patch ist eine Textdatei, deren Inhalt Git diff ähnelt, aber neben Code auch Metadaten zu Commits enthält. Beispiel: Festschreibungs-ID, Datum, Festschreibungsnachricht usw. Wir können einen Patch aus Festschreibungen erstellen und andere Personen können sie auf ihr Repository anwenden.

Jerry implementiert die strcat-Funktion für sein Projekt. Jerry kann einen Pfad seines Codes erstellen und an Tom senden. Dann kann er den empfangenen Patch auf seinen Code anwenden.

Jerry benutzt den Git format-patchBefehl zum Erstellen eines Patches für das letzte Commit. Wenn Sie einen Patch für ein bestimmtes Commit erstellen möchten, verwenden SieCOMMIT_ID mit dem Befehl format-patch.

[jerry@CentOS project]$ pwd
/home/jerry/jerry_repo/project/src

[jerry@CentOS src]$ git status -s M string_operations.c ?? string_operations [jerry@CentOS src]$ git add string_operations.c

[jerry@CentOS src]$ git commit -m "Added my_strcat function" [master b4c7f09] Added my_strcat function 1 files changed, 13 insertions(+), 0 deletions(-) [jerry@CentOS src]$ git format-patch -1
0001-Added-my_strcat-function.patch

Der obige Befehl erstellt .patchDateien im aktuellen Arbeitsverzeichnis. Tom kann diesen Patch verwenden, um seine Dateien zu ändern. Git bietet zwei Befehle zum Anwenden von Patchesgit amund git apply, beziehungsweise. Git apply Ändert die lokalen Dateien, ohne ein Commit zu erstellen git am Ändert die Datei und erstellt auch ein Commit.

Verwenden Sie den folgenden Befehl, um Patch anzuwenden und Commit zu erstellen:

[tom@CentOS src]$ pwd /home/tom/top_repo/project/src [tom@CentOS src]$ git diff

[tom@CentOS src]$ git status –s [tom@CentOS src]$ git apply 0001-Added-my_strcat-function.patch

[tom@CentOS src]$ git status -s
M string_operations.c
?? 0001-Added-my_strcat-function.patch

Der Patch wird erfolgreich angewendet. Jetzt können wir die Änderungen mithilfe von anzeigen git diff Befehl.

[tom@CentOS src]$ git diff

Der obige Befehl führt zu folgendem Ergebnis:

diff --git a/src/string_operations.c b/src/string_operations.c
index 8ab7f42..f282fcf 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,5 +1,16 @@
#include <stdio.h>
+char *my_strcat(char *t, char *s)
diff --git a/src/string_operations.c b/src/string_operations.c
index 8ab7f42..f282fcf 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,5 +1,16 @@
#include <stdio.h>
+char *my_strcat(char *t, char *s)
+
{
   +
   char *p = t;
   +
   +
   +
   while (*p)
   ++p;
   +
   while (*p++ = *s++)
   + ;
   + return t;
   +
}
+
size_t my_strlen(const char *s)
{
   const char *p = s;
   @@ -23,6 +34,7 @@ int main(void)
   {

Durch den Zweigbetrieb kann eine weitere Entwicklungslinie erstellt werden. Mit dieser Operation können wir den Entwicklungsprozess in zwei verschiedene Richtungen unterteilen. Zum Beispiel haben wir ein Produkt für die Version 6.0 veröffentlicht und möchten möglicherweise einen Zweig erstellen, damit die Entwicklung von 7.0-Funktionen von 6.0-Fehlerkorrekturen getrennt gehalten werden kann.

Zweig erstellen

Tom erstellt einen neuen Zweig mit dem Befehl git branch <Zweigname>. Wir können einen neuen Zweig aus einem bestehenden erstellen. Wir können ein bestimmtes Commit oder Tag als Ausgangspunkt verwenden. Wenn keine bestimmte Festschreibungs-ID angegeben wird, wird der Zweig mit HEAD als Ausgangspunkt erstellt.

[jerry@CentOS src]$ git branch new_branch [jerry@CentOS src]$ git branch
* master
new_branch

Ein neuer Zweig wird erstellt. Tom verwendete den Befehl git branch, um die verfügbaren Zweige aufzulisten. Git zeigt ein Sternchen vor dem aktuell ausgecheckten Zweig.

Die bildliche Darstellung der Operation zum Erstellen von Zweigen ist unten dargestellt.

Zwischen Zweigen wechseln

Jerry verwendet den Befehl git checkout, um zwischen Zweigen zu wechseln.

[jerry@CentOS src]$ git checkout new_branch Switched to branch 'new_branch' [jerry@CentOS src]$ git branch
master
* new_branch

Verknüpfung zum Erstellen und Wechseln des Zweigs

Im obigen Beispiel haben wir zwei Befehle verwendet, um Zweige zu erstellen bzw. zu wechseln. Git bietet–bOption mit dem Befehl checkout; Diese Operation erstellt einen neuen Zweig und wechselt sofort zum neuen Zweig.

[jerry@CentOS src]$ git checkout -b test_branch Switched to a new branch 'test_branch' [jerry@CentOS src]$ git branch
master
new_branch
* test_branch

Löschen Sie einen Zweig

Ein Zweig kann gelöscht werden, indem die Option –D mit dem Befehl git branch bereitgestellt wird. Wechseln Sie jedoch vor dem Löschen des vorhandenen Zweigs zum anderen Zweig.

Jerry ist derzeit auf test_branchund er will diesen Zweig entfernen. Also wechselt er den Zweig und löscht den Zweig wie unten gezeigt.

[jerry@CentOS src]$ git branch master new_branch * test_branch [jerry@CentOS src]$ git checkout master
Switched to branch 'master'

[jerry@CentOS src]$ git branch -D test_branch
Deleted branch test_branch (was 5776472).

Jetzt zeigt Git nur zwei Zweige.

[jerry@CentOS src]$ git branch
* master
new_branch

Benennen Sie einen Zweig um

Jerry beschließt, in seinem String-Operations-Projekt Unterstützung für breite Charaktere hinzuzufügen. Er hat bereits einen neuen Zweig erstellt, aber der Name des Zweigs ist nicht angemessen. Also ändert er den Filialnamen mit–m Option gefolgt von der old branch name und die new branch name.

[jerry@CentOS src]$ git branch * master new_branch [jerry@CentOS src]$ git branch -m new_branch wchar_support

Jetzt zeigt der Befehl git branch den neuen Verzweigungsnamen an.

[jerry@CentOS src]$ git branch
* master
wchar_support

Zwei Zweige zusammenführen

Jerry implementiert eine Funktion, um die Zeichenfolgenlänge einer breiten Zeichenfolge zurückzugeben. Neu wird der Code wie folgt angezeigt:

[jerry@CentOS src]$ git branch
master
* wchar_support

[jerry@CentOS src]$ pwd /home/jerry/jerry_repo/project/src [jerry@CentOS src]$ git diff

Der obige Befehl erzeugt das folgende Ergebnis:

t a/src/string_operations.c b/src/string_operations.c
index 8ab7f42..8fb4b00 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,4 +1,14 @@
#include <stdio.h>
+#include <wchar.h>
+
+size_t w_strlen(const wchar_t *s)
+
{
   +
   const wchar_t *p = s;
   +
   +
   while (*p)
   + ++p;
   + return (p - s);
   +
}

Nach dem Testen legt er seine Änderungen fest und überträgt sie auf die neue Niederlassung.

[jerry@CentOS src]$ git status -s M string_operations.c ?? string_operations [jerry@CentOS src]$ git add string_operations.c

[jerry@CentOS src]$ git commit -m 'Added w_strlen function to return string lenght of wchar_t
string'

[wchar_support 64192f9] Added w_strlen function to return string lenght of wchar_t string
1 files changed, 10 insertions(+), 0 deletions(-)

Beachten Sie, dass Jerry diese Änderungen auf den neuen Zweig überträgt, weshalb er den Namen des Zweigs verwendet hat wchar_support Anstatt von master Ast.

[jerry@CentOS src]$ git push origin wchar_support  <−−− Observer branch_name

Der obige Befehl führt zu folgendem Ergebnis.

Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 507 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
* [new branch]
wchar_support -> wchar_support

Nach dem Festschreiben der Änderungen wird der neue Zweig wie folgt angezeigt:

Tom ist neugierig, was Jerry in seiner Privatfiliale macht und überprüft das Protokoll von der wchar_support Ast.

[tom@CentOS src]$ pwd /home/tom/top_repo/project/src [tom@CentOS src]$ git log origin/wchar_support -2

Der obige Befehl führt zu folgendem Ergebnis.

commit 64192f91d7cc2bcdf3bf946dd33ece63b74184a3
Author: Jerry Mouse <[email protected]>
Date: Wed Sep 11 16:10:06 2013 +0530

Added w_strlen function to return string lenght of wchar_t string


commit 577647211ed44fe2ae479427a0668a4f12ed71a1
Author: Tom Cat <[email protected]>
Date: Wed Sep 11 10:21:20 2013 +0530

Removed executable binary

Durch das Anzeigen von Commit-Nachrichten erkennt Tom, dass Jerry die Strlen-Funktion für Wide Character implementiert hat und dass er dieselbe Funktionalität im Master-Zweig haben möchte. Anstatt erneut zu implementieren, beschließt er, Jerrys Code zu übernehmen, indem er seinen Zweig mit dem Hauptzweig zusammenführt.

[tom@CentOS project]$ git branch * master [tom@CentOS project]$ pwd
/home/tom/top_repo/project

[tom@CentOS project]$ git merge origin/wchar_support
Updating 5776472..64192f9
Fast-forward
src/string_operations.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)

Nach dem Zusammenführungsvorgang wird der Hauptzweig wie folgt angezeigt:

Nun der Zweig wchar_supportwurde mit dem Hauptzweig zusammengeführt. Wir können dies überprüfen, indem wir die Festschreibungsnachricht oder die in der Datei string_operation.c vorgenommenen Änderungen anzeigen.

[tom@CentOS project]$ cd src/

[tom@CentOS src]$ git log -1

commit 64192f91d7cc2bcdf3bf946dd33ece63b74184a3
Author: Jerry Mouse 
      
        Date: Wed Sep 11 16:10:06 2013 +0530 Added w_strlen function to return string lenght of wchar_t string [tom@CentOS src]$ head -12 string_operations.c 
      

Der obige Befehl führt zu folgendem Ergebnis.

#include <stdio.h>
#include <wchar.h>
size_t w_strlen(const wchar_t *s)
{
   const wchar_t *p = s;

   while (*p)
      ++p;

   return (p - s);
}

Nach dem Testen überträgt er seine Codeänderungen an den Hauptzweig.

[tom@CentOS src]$ git push origin master
Total 0 (delta 0), reused 0 (delta 0)
To [email protected]:project.git
5776472..64192f9 master −> master

Zweige neu gründen

Der Git-Rebase-Befehl ist ein Verzweigungszusammenführungsbefehl, der Unterschied besteht jedoch darin, dass die Reihenfolge der Festschreibungen geändert wird.

Der Git-Merge-Befehl versucht, die Commits anderer Zweige über den HEAD des aktuellen lokalen Zweigs zu setzen. Zum Beispiel hat Ihr lokaler Zweig Commits A -> B -> C -> D und der Zusammenführungszweig hat Commits A -> B -> X -> Y, dann konvertiert Git Merge den aktuellen lokalen Zweig in etwas wie A -> B -> C -> D -> X -> Y.

Der Befehl Git rebase versucht, den gemeinsamen Vorfahren zwischen dem aktuellen lokalen Zweig und dem Zusammenführungszweig herauszufinden. Anschließend werden die Commits an den lokalen Zweig weitergeleitet, indem die Reihenfolge der Commits im aktuellen lokalen Zweig geändert wird. Wenn Ihr lokaler Zweig beispielsweise Commits A -> B -> C -> D hat und der Zusammenführungszweig Commits A -> B -> X -> Y hat, konvertiert Git Rebase den aktuellen lokalen Zweig in etwas wie A - > B -> X -> Y -> C -> D.

Wenn mehrere Entwickler an einem einzelnen Remote-Repository arbeiten, können Sie die Reihenfolge der Commits im Remote-Repository nicht ändern. In dieser Situation können Sie die Rebase-Operation verwenden, um Ihre lokalen Commits über die Remote-Repository-Commits zu setzen, und Sie können diese Änderungen übertragen.

Führen Sie Änderungen in wchar_support Branch durch

Jerry arbeitet an der wchar_supportAst. Er ändert den Namen der Funktionen und übernimmt nach dem Testen seine Änderungen.

[jerry@CentOS src]$ git branch
 master
* wchar_support
[jerry@CentOS src]$ git diff

Der obige Befehl erzeugt das folgende Ergebnis:

diff --git a/src/string_operations.c b/src/string_operations.c
index 8fb4b00..01ff4e0 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,7 +1,7 @@
#include <stdio.h>
#include <wchar.h>
-size_t w_strlen(const wchar_t *s)
+size_t my_wstrlen(const wchar_t *s)
{
   const wchar_t *p = s;

Nach Überprüfung des Codes schreibt er seine Änderungen fest.

[jerry@CentOS src]$ git status -s
M string_operations.c

[jerry@CentOS src]$ git add string_operations.c [jerry@CentOS src]$ git commit -m 'Changed function name'
[wchar_support 3789fe8] Changed function name
1 files changed, 1 insertions(+), 1 deletions(-)

[jerry@CentOS src]$ git push origin wchar_support

Der obige Befehl führt zu folgendem Ergebnis:

Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 409 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
64192f9..3789fe8 wchar_support -> wchar_support

Führen Sie Änderungen in der Hauptniederlassung durch

Währenddessen ändert Tom in der Hauptniederlassung auch den Namen derselben Funktion und überträgt seine Änderungen an die Hauptniederlassung.

[tom@CentOS src]$ git branch
* master
[tom@CentOS src]$ git diff

Der obige Befehl erzeugt das folgende Ergebnis:

diff --git a/src/string_operations.c b/src/string_operations.c
index 8fb4b00..52bec84 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,7 +1,8 @@
#include <stdio.h>
#include <wchar.h>
-size_t w_strlen(const wchar_t *s)
+/* wide character strlen fucntion */
+size_t my_wc_strlen(const wchar_t *s)
{
   const wchar_t *p = s;

Nachdem er diff überprüft hat, schreibt er seine Änderungen fest.

[tom@CentOS src]$ git status -s
M string_operations.c

[tom@CentOS src]$ git add string_operations.c [tom@CentOS src]$ git commit -m 'Changed function name from w_strlen to my_wc_strlen'
[master ad4b530] Changed function name from w_strlen to my_wc_strlen
1 files changed, 2 insertions(+), 1 deletions(-)

[tom@CentOS src]$ git push origin master

Der obige Befehl führt zu folgendem Ergebnis:

Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 470 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
64192f9..ad4b530 master -> master

Auf der wchar_supportBranch implementiert Jerry die strchr-Funktion für breite Zeichenfolgen. Nach dem Testen verpflichtet er sich und schiebt seine Änderungen an diewchar_support Ast.

[jerry@CentOS src]$ git branch
master
* wchar_support
[jerry@CentOS src]$ git diff

Der obige Befehl erzeugt das folgende Ergebnis:

diff --git a/src/string_operations.c b/src/string_operations.c
index 01ff4e0..163a779 100644
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@ -1,6 +1,16 @@
#include <stdio.h>
#include <wchar.h>
+wchar_t *my_wstrchr(wchar_t *ws, wchar_t wc)
+
{
   +
   while (*ws) 
   {
      +
      if (*ws == wc)
      +
      return ws;
      +
      ++ws;
      + 
   }
   + return NULL;
   +
}
+
size_t my_wstrlen(const wchar_t *s)
{
   const wchar_t *p = s;

Nach der Überprüfung legt er seine Änderungen fest.

[jerry@CentOS src]$ git status -s
M string_operations.c

[jerry@CentOS src]$ git add string_operations.c [jerry@CentOS src]$ git commit -m 'Addded strchr function for wide character string'
[wchar_support 9d201a9] Addded strchr function for wide character string
1 files changed, 10 insertions(+), 0 deletions(-)

[jerry@CentOS src]$ git push origin wchar_support

Der obige Befehl führt zu folgendem Ergebnis:

Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 516 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
To [email protected]:project.git
3789fe8..9d201a9 wchar_support -> wchar_support

Konflikte angehen

Tom will sehen, was Jerry in seiner Privatniederlassung macht, also versucht er, die neuesten Änderungen aus dem zu holen wchar_support Verzweigen, aber Git bricht den Vorgang mit der folgenden Fehlermeldung ab.

[tom@CentOS src]$ git pull origin wchar_support

Der obige Befehl erzeugt das folgende Ergebnis:

remote: Counting objects: 11, done.
63Git Tutorials
remote: Compressing objects: 100% (8/8), done.
remote: Total 8 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (8/8), done.
From git.server.com:project
* branch
wchar_support -> FETCH_HEAD
Auto-merging src/string_operations.c
CONFLICT (content): Merge conflict in src/string_operations.c
Automatic merge failed; fix conflicts and then commit the result.

Konflikte lösen

Aus der Fehlermeldung geht hervor, dass in src / string_operations.c ein Konflikt vorliegt. Er führt den Befehl git diff aus, um weitere Details anzuzeigen.

[tom@CentOS src]$ git diff

Der obige Befehl erzeugt das folgende Ergebnis:

diff --cc src/string_operations.c
index 52bec84,163a779..0000000
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@@ -1,8 -1,17 +1,22 @@@
#include <stdio.h>
#include <wchar.h>
++<<<<<<< HEAD
+/* wide character strlen fucntion */
+size_t my_wc_strlen(const wchar_t *s)
++=======
+ wchar_t *my_wstrchr(wchar_t *ws, wchar_t wc)
+
{
   +
   +
   while (*ws) 
   {
      if (*ws == wc)
      +
      return ws;
      +
      ++ws;
      + 
   }
   + return NULL;
   +
}
+
+ size_t my_wstrlen(const wchar_t *s)
++>>>>>>>9d201a9c61bc4713f4095175f8954b642dae8f86
{
   const wchar_t *p = s;

Da sowohl Tom als auch Jerry den Namen derselben Funktion geändert haben, ist Git verwirrt und fordert den Benutzer auf, den Konflikt manuell zu lösen.

Tom beschließt, den von Jerry vorgeschlagenen Funktionsnamen beizubehalten, behält jedoch den von ihm hinzugefügten Kommentar bei. Nach dem Entfernen der Konfliktmarkierungen sieht Git Diff folgendermaßen aus.

[tom@CentOS src]$ git diff

Der obige Befehl erzeugt das folgende Ergebnis.

diff --cc src/string_operations.c
diff --cc src/string_operations.c
index 52bec84,163a779..0000000
--- a/src/string_operations.c
+++ b/src/string_operations.c
@@@ -1,8 -1,17 +1,18 @@@
#include <stdio.h>
#include <wchar.h>
+ wchar_t *my_wstrchr(wchar_t *ws, wchar_t wc)
+
{
   +
   while (*ws) 
   {
      +
      if (*ws == wc)
      +
      return ws;
      +
      ++ws;
      + 
   }
   + return NULL;
   +
}
+
+/* wide character strlen fucntion */
- size_t my_wc_strlen(const wchar_t *s)
+ size_t my_wstrlen(const wchar_t *s)
{
   const wchar_t *p = s;

Da Tom die Dateien geändert hat, muss er diese Änderungen zuerst festschreiben und danach kann er die Änderungen abrufen.

[tom@CentOS src]$ git commit -a -m 'Resolved conflict' [master 6b1ac36] Resolved conflict [tom@CentOS src]$ git pull origin wchar_support.

Tom hat den Konflikt gelöst, jetzt ist die Pull-Operation erfolgreich.

GNU / Linux und Mac OS verwendet line-feed (LF)oder neue Zeile als Zeilenendezeichen, während Windows verwendet line-feed and carriage-return (LFCR) Kombination zur Darstellung des Zeilenendezeichens.

Um unnötige Commits aufgrund dieser Unterschiede am Zeilenende zu vermeiden, müssen wir den Git-Client so konfigurieren, dass er dasselbe Zeilenende in das Git-Repository schreibt.

Für Windows-Systeme können wir den Git-Client so konfigurieren, dass Zeilenenden in konvertiert werden CRLF Formatieren Sie beim Auschecken und konvertieren Sie sie zurück in LFFormat während des Festschreibungsvorgangs. Die folgenden Einstellungen reichen aus.

[tom@CentOS project]$ git config --global core.autocrlf true

Für GNU / Linux oder Mac OS können wir den Git-Client so konfigurieren, dass Zeilenenden von konvertiert werden CRLF zu LF während des Auscheckvorgangs.

[tom@CentOS project]$ git config --global core.autocrlf input

GitHubist ein webbasierter Hosting-Service für Softwareentwicklungsprojekte, der das Git-Revisionskontrollsystem verwendet. Die Standard-GUI-Anwendung (Windows, Mac, GNU / Linux) kann direkt von der Website des Dienstes heruntergeladen werden. In dieser Sitzung sehen wir jedoch nur den CLI-Teil.

Erstellen Sie das GitHub-Repository

Gehen Sie zu github.com . Wenn Sie bereits die habenGitHubKonto, dann melden Sie sich mit diesem Konto an oder erstellen Sie ein neues. Befolgen Sie die Schritte auf der Website github.com , um ein neues Repository zu erstellen.

Push-Betrieb

Tom beschließt, die zu verwenden GitHubServer. Um ein neues Projekt zu starten, erstellt er ein neues Verzeichnis und eine Datei darin.

[tom@CentOS]$ mkdir github_repo [tom@CentOS]$ cd github_repo/

[tom@CentOS]$ vi hello.c [tom@CentOS]$ make hello
cc hello.c -o hello

[tom@CentOS]$ ./hello

Der obige Befehl führt zu folgendem Ergebnis:

Hello, World !!!

Nachdem er seinen Code überprüft hat, initialisiert er das Verzeichnis mit dem Befehl git init und schreibt seine Änderungen lokal fest.

[tom@CentOS]$ git init
Initialized empty Git repository in /home/tom/github_repo/.git/

[tom@CentOS]$ git status -s ?? hello ?? hello.c [tom@CentOS]$ git add hello.c

[tom@CentOS]$ git status -s A hello.c ?? hello [tom@CentOS]$ git commit -m 'Initial commit'

Danach fügt er das hinzu GitHub Repository-URL als Remote-Ursprung und überträgt seine Änderungen an das Remote-Repository.

[tom@CentOS]$ git remote add origin https://github.com/kangralkar/testing_repo.git [tom@CentOS]$ git push -u origin master

Push-Betrieb fragt nach GitHubBenutzername und Passwort. Nach erfolgreicher Authentifizierung ist der Vorgang erfolgreich.

Der obige Befehl führt zu folgendem Ergebnis:

Username for 'https://github.com': kangralkar
Password for 'https://[email protected]': 
Counting objects: 3, done.
Writing objects: 100% (3/3), 214 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/kangralkar/test_repo.git
 * [new branch]      master −> master
 Branch master set up to track remote branch master from origin.

Ab sofort kann Tom alle Änderungen an der GitHubRepository. Er kann alle in diesem Kapitel beschriebenen Befehle mit dem verwendenGitHub Repository.

Pull-Betrieb

Tom schob erfolgreich alle seine Änderungen an die GitHubRepository. Jetzt können andere Entwickler diese Änderungen anzeigen, indem sie einen Klonvorgang ausführen oder ihr lokales Repository aktualisieren.

Jerry erstellt ein neues Verzeichnis in seinem Home-Verzeichnis und klont das GitHub Repository mit dem Befehl git clone.

[jerry@CentOS]$ pwd /home/jerry [jerry@CentOS]$ mkdir jerry_repo

[jerry@CentOS]$ git clone https://github.com/kangralkar/test_repo.git

Der obige Befehl führt zu folgendem Ergebnis:

Cloning into 'test_repo'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 3 (delta 0)
Unpacking objects: 100% (3/3), done.

Er überprüft den Verzeichnisinhalt, indem er den Befehl ls ausführt.

[jerry@CentOS]$ ls
test_repo

[jerry@CentOS]$ ls test_repo/
hello.c