Git-Tutorial: Beginnen Sie mit der Git-Versionskontrolle

Dieser Artikel führt Sie in Git ein, einschließlich der Installation der erforderlichen Software für den Zugriff auf Git-Server, auf denen Ihr Softwareprojekt gespeichert wird.

Versionskontrollkonzepte

Um Git und das Konzept der Versionskontrolle zu verstehen, ist es hilfreich, die Versionskontrolle aus einer historischen Perspektive zu betrachten. Es gab drei Generationen von Versionskontrollsoftware.

Die erste Generation

Die erste Generation war sehr einfach. Entwickler arbeiteten auf demselben physischen System und "checkten" jeweils eine Datei aus.

Diese Generation von Versionskontrollsoftware verwendete eine Technik namens Dateisperrung . Wenn ein Entwickler eine Datei auscheckte, wurde sie gesperrt, sodass kein anderer Entwickler die Datei bearbeiten konnte. 

Beispiele für Versionskontrollsoftware der ersten Generation sind das Revisionskontrollsystem (RCS) und das Quellcode-Kontrollsystem (SCCS).

Die zweite Generation

Die Probleme mit der ersten Generation umfassten Folgendes:

  • Es konnte jeweils nur ein Entwickler an einer Datei arbeiten. Dies führte zu einem Engpass im Entwicklungsprozess.

  • Entwickler mussten sich direkt bei dem System anmelden, das die Versionskontrollsoftware enthielt.

Diese Probleme wurden in der zweiten Generation der Versionskontrollsoftware gelöst. In der zweiten Generation werden Dateien auf einem zentralen Server in einem Repository gespeichert. Entwickler können separate Kopien einer Datei auschecken. Wenn der Entwickler die Arbeit an einer Datei abgeschlossen hat, wird die Datei in das Repository eingecheckt. 

Wenn zwei Entwickler dieselbe Version einer Datei auschecken, besteht das Potenzial für Probleme. Dies wird durch einen Prozess erledigt, der als Zusammenführung bezeichnet wird .

Was ist eine Fusion? Angenommen, zwei Entwickler, Bob und Sue, sehen sich Version 5 einer Datei mit dem Namen an abc.txt. Nachdem Bob seine Arbeit abgeschlossen hat, checkt er die Datei wieder ein. In der Regel führt dies zu einer neuen Version der Datei, Version 6.

Einige Zeit später checkt Sue ihre Akte ein. Diese neue Datei muss ihre Änderungen und Bobs Änderungen enthalten. Dies wird durch den Prozess einer Zusammenführung erreicht.

Abhängig von der von Ihnen verwendeten Versionskontrollsoftware gibt es verschiedene Möglichkeiten, diese Zusammenführung durchzuführen. In einigen Fällen, z. B. wenn Bob und Sue an völlig unterschiedlichen Teilen der Datei gearbeitet haben, ist der Zusammenführungsprozess sehr einfach. In Fällen, in denen Sue und Bob an denselben Codezeilen in der Datei gearbeitet haben, kann der Zusammenführungsprozess jedoch komplexer sein. In diesen Fällen muss Sue Entscheidungen treffen, z. B. ob Bobs Code oder ihr Code in der neuen Version der Datei enthalten sein wird.

Nach Abschluss des Zusammenführungsprozesses wird die Datei in das Repository übertragen. Das Festschreiben einer Datei bedeutet im Wesentlichen, eine neue Version im Repository zu erstellen. In diesem Fall Version 7 der Datei.

Beispiele für Versionskontrollsoftware der zweiten Generation sind Concurrent Versions System (CVS) und Subversion.

Die dritte Generation

Die dritte Generation wird als verteilte Versionskontrollsysteme (DVCS) bezeichnet. Wie bei der zweiten Generation enthält ein zentraler Repository-Server alle Dateien für das Projekt. Entwickler checken jedoch keine einzelnen Dateien aus dem Repository aus. Stattdessen wird das gesamte Projekt ausgecheckt, sodass der Entwickler nicht nur einzelne Dateien, sondern den gesamten Satz von Dateien bearbeiten kann. 

Ein weiterer (sehr großer) Unterschied zwischen der zweiten und dritten Generation von Versionskontrollsoftware hängt mit der Funktionsweise des Zusammenführungs- und Festschreibungsprozesses zusammen. Wie bereits erwähnt, besteht der Schritt in der zweiten Generation darin, eine Zusammenführung durchzuführen und die neue Version dann in das Repository zu übernehmen.

Mit der Versionskontrollsoftware der dritten Generation werden Dateien eingecheckt und dann zusammengeführt. 

Angenommen, zwei Entwickler checken eine Datei aus, die auf der dritten Version basiert. Wenn ein Entwickler diese Datei eincheckt, was zu einer Version 4 der Datei führt, muss der zweite Entwickler zuerst die Änderungen aus seiner ausgecheckten Kopie mit den Änderungen von Version 4 (und möglicherweise anderen Versionen) zusammenführen. Nach Abschluss der Zusammenführung kann die neue Version als Version 5 in das Repository übernommen werden.

Wenn Sie sich auf das konzentrieren, was sich im Repository befindet (der mittlere Teil jeder Phase), sehen Sie, dass es eine sehr gerade Entwicklungslinie gibt (Ver1, Ver2, Ver3, Ver4, Ver5 usw.). Dieser einfache Ansatz für die Softwareentwicklung wirft einige potenzielle Probleme auf:

  • Wenn ein Entwickler vor dem Festschreiben zusammengeführt werden muss, möchte er seine Änderungen häufig nicht regelmäßig festschreiben. Der Zusammenführungsprozess kann schmerzhaft sein, und Entwickler entscheiden sich möglicherweise dafür, nur bis später zu warten und eine Zusammenführung anstelle einer Reihe regulärer Zusammenführungen durchzuführen. Dies wirkt sich negativ auf die Softwareentwicklung aus, da einer Datei plötzlich riesige Codestücke hinzugefügt werden. Darüber hinaus möchten Sie Entwickler dazu ermutigen, Änderungen am Repository vorzunehmen, genau wie Sie jemanden, der ein Dokument schreibt, dazu ermutigen möchten, es regelmäßig zu speichern.
  • Sehr wichtig: Version 5 in diesem Beispiel ist nicht unbedingt die Arbeit, die der Entwickler ursprünglich abgeschlossen hat. Während des Zusammenführungsprozesses verwirft der Entwickler möglicherweise einen Teil seiner Arbeit, um den Zusammenführungsprozess abzuschließen. Dies ist nicht ideal, da dadurch möglicherweise guter Code verloren geht.

A better, although arguably more complex, technique can be used. It is called directed acyclic graph (DAG).

Picture the same scenario as above, where two developers check out version 3 of a file. Here, if one developer checks that file in, it still results in a version 4 of the file. However, the second check-in process results in a version 5 file that is not based on version 4, but rather independent of version 4. In the next stage of the process, versions 4 and 5 of the file are merged to create a version 6.

Although this process is more complex (and, potentially, much more complex if you have a large number of developers), it does provide some advantages over a single line of development:

  • Developers can commit their changes on a regular basis and not have to worry about merging until a later time.
  • The merging process could be delegated to a specific developer who has a better idea of the entire project or code than the other developers have.
  • At any time, the project manager can go back and see exactly what work each individual developer created.

Certainly an argument exists for both methods. However, keep in mind that this article focuses on Git, which uses the directed acyclic graph method of third-generation version control systems.

Installing Git

You might already have Git on your system because it is sometimes installed by default (or another administrator might have installed it). If you have access to the system as a regular user, you can execute the following command to determine whether you have Git installed:

[email protected]:~$ which git /usr/bin/git

If Git is installed, then the path to the git command is provided, as shown in the preceding command. If it isn’t installed, then you either get no output or an error like the following:

[[email protected] ~]# which git /usr/bin/which: no git in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/ bin:/usr/sbin:/bin:/sbin:/root/bin)

As an administrator on a Debian-based system, you can use the dpkg command to determine whether the Git package has been installed:

[email protected]:~# dpkg -l git Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/ ➥Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-========-=============-=============-======================================== ii git 1:1.9.1-1ubun amd64 fast, scalable, distributed ➥revision con

As an administrator on a Red Hat–based system, you could use the rpm command to determine whether the git package has been installed:

[[email protected] ~]# rpm -q git git-1.8.3.1-6.el7_2.1.x86_64

If Git isn’t installed on your system, you must either log in as the root user or use sudo or su to install the software. If you are logged in as the root user on a Debian-based system, you can use the following command to install Git:

apt-get install git

If you are logged in as the root user on a Red Hat–based system, you can use the following command to install Git:

yum install git

Get more than Git

Consider installing the software package git-all. This package includes some additional dependency packages that add more power to Git. Although you might not use these features in the beginning, having them available when you are ready to perform more advanced Git functions will be good.

Git concepts and features

One of the challenges to using Git is just understanding the concepts behind it. If you don’t understand the concepts, then all the commands just seem like some sort of black magic. This section focuses on the critical Git concepts as well as introduces you to some of the basic commands.

Git stages

It is very important to remember that you check out an entire project and that most of the work you do will be local to the system that you are working on. The files that you check out will be placed in a directory under your home directory.

To get a copy of a project from a Git repository, you use a process called cloning. Cloning doesn’t just create a copy of all the files from the repository; it actually performs three primary functions:

  • Creates a local repository of the project under the project_name/.git directory in your home directory. The files of the project in this location are considered to be checked out from the central repository.
  • Creates a directory where you can directly see the files. This is called the working area. Changes made in the working area are not immediately version controlled.
  • Creates a staging area. The staging area is designed to store changes to files before you commit them to the local repository.

This means that if you were to clone a project called Jacumba, the entire project would be stored in the Jacumba/.git directory under your home directory. You should not try to modify these directly. Instead, look directly in the ~/Jacumba directory tol see the files from the project. These are the files that you should change.

Suppose you made a change to a file, but you have to work on some other files before you were ready to commit changes to the local repository. In that case, you would stage the file that you have finished working on. This would prepare it to be committed to the local repository.

After you make all changes and stage all files, then you commit them to the local repository. 

Realize that committing the staged files only sends them to the local repository. This means that only you have access to the changes that have been made. The process of checking in the new versions to the central repository is called a push.

Choosing your Git repository host

First, the good news: Many organizations provide Git hosting—at the time of this writing, there are more than two dozen choices. This means you have many options to choose from. That’s the good news … and the bad news.

It is only bad news because it means you really need to spend some time researching the pros and cons of the hosting organizations. For example, most don’t charge for basic hosting but do charge for large-scale projects. Some only provide public repositories (anyone can see your repository) whereas others let you create private repositories. There are many other features to consider.

One feature that might be high on your list is a web interface. Although you can do just about all repository operations locally on your system, being able to perform some operations via a web interface can be very useful. Explore the interface that is provided before making your choice.

At the very least, I recommend considering the following:

  • //bitbucket.org
  • //www.cloudforge.com
  • //www.codebasehq.com
  • //github.com
  • //gitlab.com

Note that I chose Gitlab.com for the examples below. Any of the hosts in the preceding list would have worked just as well; I chose Gitlab.com simply because it happened to be the one I used on my last Git project.

Configuring Git

Now that you have gotten through all the theory, it is time to actually do something with Git. This next section assumes the following:

  • You have installed the git or git-all software package on your system.
  • You have created an account on a Git hosting service.

The first thing you want to do is perform some basic setup. Whenever you perform a commit operation, your name and email address will be included in the metadata. To set this information, execute the following commands:

ocs @ ubuntu: ~ $ git config --globaler Benutzername "Bo Rothwell" ocs @ ubuntu: ~ $ git config --globaler Benutzer.email "[email protected]"

Natürlich werden Sie durch "Bo Rothwell"Ihren Namen und "[email protected]"Ihre E-Mail-Adresse ersetzen . Der nächste Schritt besteht darin, Ihr Projekt vom Git-Hosting-Service zu klonen. Beachten Sie, dass sich vor dem Klonen nur eine Datei im Home-Verzeichnis des Benutzers befindet:

ocs @ ubuntu: ~ $ ls first.sh

Folgendes hat ein Projekt namens ocs geklont: