Pro Git. Scott Chacon *

Save this PDF as:

Größe: px
Ab Seite anzeigen:

Download "Pro Git. Scott Chacon * 2012-05-09"


1 Pro Git Scott Chacon * * This is the PDF file for the Pro Git book contents. It is licensed under the Creative Commons Attribution-Non Commercial-Share Alike 3.0 license. I hope you enjoy it, I hope it helps you learn Git, and I hope you ll support Apress and me by purchasing a print copy of the book at Amazon:


3 Contents 1 Los geht s Wozu Versionskontrolle? Local Version Control Systems Lokale Versionskontrollsysteme Centralized Version Control Systems Zentralisierte Versionskontrollsysteme Distributed Version Control Systems A Short History of Git Die Geschichte von Git Git Basics Git Grundlagen Snapshots, Not Differences Snapshots, nicht Diffs Nearly Every Operation Is Local Fast jede Operation ist lokal Git Has Integrity Git stellt Integrität sicher Git Generally Only Adds Data Git verwaltet fast ausschließlich Daten The Three States Die drei Zustände Installing Git Git Installieren Installing from Source Vom Quellcode aus installieren Installing on Linux Installation unter Linux Installing on Mac Installation unter Mac OS X Installing on Windows Installation unter Windows First-Time Git Setup Git konfigurieren Your Identity Deine Identität iii

4 1.9.3 Your Editor Dein Editor Your Diff Tool Dein Diff Programm Checking Your Settings Deine Einstellungen überprüfen Getting Help Hilfe finden Summary Git Basics 19 3 Git Grundlagen Getting a Git Repository Ein Git Repository anlegen Initializing a Repository in an Existing Directory Ein existierendes Verzeichnis als Git Repository initialisieren Cloning an Existing Repository Ein existierendes Repository klonen Recording Changes to the Repository Änderungen am Repository nachverfolgen Checking the Status of Your Files Den Zustand deiner Dateien prüfen Tracking New Files Neue Dateien zur Versionskontrolle hinzufügen Staging Modified Files Ignoring Files Dateien ignorieren Viewing Your Staged and Unstaged Changes Die Änderungen in der Staging Area durchsehen Committing Your Changes Einen Commit anlegen Skipping the Staging Area Die Staging Area überspringen Removing Files Dateien entfernen Moving Files Dateien verschieben Viewing the Commit History Die Commit Historie anzeigen Limiting Log Output Using a GUI to Visualize History Eine GUI verwenden um die Historie anzuzeigen Undoing Things Änderungen rückgängig machen Changing Your Last Commit iv

5 3.8.2 Den letzten Commit ändern Unstaging a Staged File Änderungen aus der Staging Area nehmen Unmodifying a Modified File Eine Änderung an einer Datei rückgängig machen Working with Remotes Mit externen Repositories arbeiten Showing Your Remotes Externe Repositories anzeigen Adding Remote Repositories Externe Repositories hinzufügen Fetching and Pulling from Your Remotes Aus externen Repositories herunterladen und ziehen Pushing to Your Remotes Änderungen in ein externes Repository hochladen Inspecting a Remote Ein externes Repository inspizieren Removing and Renaming Remotes Verweise auf externe Repositories löschen und umbenennen Tagging Tagging Listing Your Tags Vorhandene Tags anzeigen Creating Tags Neue Tags anlegen Annotated Tags Kommentierte Tags (xxx) Signed Tags Signierte Tags Lightweight Tags Leichte Tags (xxx) Verifying Tags Tags verifizieren Tagging Later Nachträglich taggen Sharing Tags Tags hochladen (xxx) Tips and Tricks Tipps und Tricks Auto-Completion Auto-Vervollständigung Git Aliases Git Aliase Summary Zusammenfassung v

6 4 Git Branching Was eine Branch ist What a Branch Is Basic Branching and Merging Branching Grundlagen Basic Branching Die Grundlagen des Zusammenführens (Mergen) Basic Merging Grundlegende merge Konflikte Basic Merge Conflicts Branch Management Branching Workflows Langfristige Branches Long-Running Branches Themen-Branches Topic Branches Externe Branches Remote Branches Hochladen Pushing Tracking Branches Deleting Remote Branches Rebasing The Basic Rebase More Interesting Rebases The Perils of Rebasing Summary Git on the Server 97 6 Git auf dem Server The Protocols Die Protokolle Local Protocol Lokales Protokoll The Pros SUBSUBSECTION: Die Vorteile The Cons SUBSUBSECTION: Die Nachteile The SSH Protocol Das SSH Protokoll The Pros Die Vorteile The Cons Die Nachteile The Git Protocol Das Git Protokoll The Pros vi

7 Die Vorteile The Cons Die Nachteile The HTTP/S Protocol Das HTTP/S Protokoll The Pros Die Vorteile The Cons Die Nachteile Getting Git on a Server Git auf einen Server bekommen Putting the Bare Repository on a Server Inbetriebnahme des einfachen Repository auf einem Server Small Setups Kleine Konfigurationen SSH Access SSH-Zugriff Generating Your SSH Public Key Generiere deinen öffentlichen SSH-Schlüssel Setting Up the Server Einrichten des Servers Public Access Öffentlicher Zugang GitWeb Gitosis Gitolite Installing Customising the Install Config File and Access Control Rules Advanced Access Control with deny rules Restricting pushes by files changed Personal Branches Wildcard repositories Other Features Git Daemon Hosted Git GitHub Setting Up a User Account Creating a New Repository Importing from Subversion Adding Collaborators Your Project Forking Projects GitHub Summary Summary vii

8 7 Distributed Git Distribuierte Arbeit mit Git (xxx) Distributed Workflows Distribuierte Workflows Centralized Workflow Zentralisierter Workflow Integration-Manager Workflow Integration-Manager Workflow Dictator and Lieutenants Workflow Diktator und Leutnants Workflow Contributing to a Project An einem Projekt mitarbeiten Commit Guidelines Commit Richtlinien Private Small Team Kleine Teams Private Managed Team Teil-Teams mit Integration Manager Public Small Project Kleine, öffentliche Projekte Public Large Project Große öffentliche Projekte Summary Zusammenfassung Maintaining a Project Ein Projekt betreiben Working in Topic Branches In Topic Branches arbeiten Applying Patches from Patches aus s verwenden Applying a Patch with apply Applying a Patch with am Checking Out Remote Branches Determining What Is Introduced Neuigkeiten durchsehen Integrating Contributed Work Beiträge anderer integrieren Merging Workflows Merge Workflows Large-Merging Workflows Workflows für umfassende Merges Rebasing and Cherry Picking Workflows Rebase und Cherry Picking Workflows Tagging Your Releases Releases taggen viii

9 Generating a Build Number Eine Build Nummer generieren Preparing a Release Ein Release vorbereiten The Shortlog Das Shortlog Summary Zusammenfassung Git Tools Git Tools Revision Selection Revision Auswahl Single Revisions Einzelne Revisionen Short SHA Abgekürztes SHA A SHORT NOTE ABOUT SHA EINE KURVE NOTIZ ÜBER SHA Branch References Branch Referenzen RefLog Shortnames RefLog Kurznamen Ancestry References Vorfahren Referenzen Commit Ranges Commit Reihen Double Dot Zwei-Punkte Syntax Multiple Points Mehrfache Punkte (xxx) Triple Dot Drei-Punkte Syntax Interactive Staging Interaktives Stagen Staging and Unstaging Files Dateien stagen und unstagen (xxx) Staging Patches Patches stagen Stashing Stashing Your Work Creating a Branch from a Stash Rewriting History Changing the Last Commit Changing Multiple Commit Messages ix

10 Reordering Commits Squashing a Commit Splitting a Commit The Nuclear Option: filter-branch Removing a File from Every Commit Making a Subdirectory the New Root Changing Addresses Globally Debugging with Git File Annotation Binary Search Submodules Starting with Submodules Cloning a Project with Submodules Superprojects Issues with Submodules Subtree Merging Summary Customizing Git Git Personalisieren Git Configuration Git Konfiguration Basic Client Configuration Grundlegende Client Konfiguration core.editor commit.template core.pager user.signingkey core.excludesfile help.autocorrect Colors in Git color.ui color.* External Merge and Diff Tools Formatting and Whitespace Formatierung und Fuellzeichen core.autocrlf core.whitespace Server Configuration receive.fsckobjects receive.denynonfastforwards receive.denydeletes Git Attributes Git Attribute Binary Files x

11 Binärdateien Identifying Binary Files SUBSUBSECTION: Binärdateien erkennen Diffing Binary Files SUBSUBSECTION: Diff bei Binärdateien Keyword Expansion Schluesselworte Erweitern Exporting Your Repository Exportieren Deines Repositories export-ignore export-subst Merge Strategies Merge Strategien Git Hooks Git Hooks Installing a Hook Installieren eines Hooks Client-Side Hooks Client-seitige Hooks Committing-Workflow Hooks SUBSUBSECTION: Hooks fuer einen Commit Arbeitsablauf Workflow Hooks SUBSUBSECTION: Hooks fuer Arbeitsablauf253 Other Client Hooks SUBSUBSECTION: Andere Hooks fuer den Client Server-Side Hooks Serverseitige Hooks pre-receive and post-receive SUBSUBSECTION: pre-receive und post-receive255 update An Example Git-Enforced Policy Server-Side Hook Enforcing a Specific Commit-Message Format Enforcing a User-Based ACL System Enforcing Fast-Forward-Only Pushes Client-Side Hooks Summary Git und andere Versionsverwaltungen Git und Subversion git svn To follow along, you first need to create a new local Subversion repository: Installation Die ersten Schritte (Getting Started) Änderungen ins lokale Repository übernehmen Probleme beim Benutzen von Branches Subversion-Zweige Einen neuen SVN-Zweig anlegen Den aktiven Zweig wechseln Subversion Befehle xi

12 Historie im SVN-Stil SVN Vermerke (SVN Annotation) SVN-Server-Informationen Ignorieren, was Subversion ignoriert Zusammenfassung von Git-Svn Zu Git umziehen Import Subversion Perforce Ein Import-Tool im Eigenbau Zusammenfassung Git Internals Git Internas Plumbing and Porcelain Plumbing und Porcelain Git Objects Git Objekte Tree Objects Baum Objekte Commit Objects Objekte committen Object Storage Objekt Speicher Git References Git Referenzen The HEAD Der HEAD Tags Tags Remotes Externe Referenzen Packfiles xxx The Refspec Die Refspec Pushing Refspecs Refspecs pushen Deleting References Referenzen löschen Transfer Protocols Transfer Protokolle The Dumb Protocol Das dumme Protokoll The Smart Protocol xii

13 Das Smart Protokoll (xxx) Uploading Data Daten hochladen Downloading Data Downloading Data Maintenance and Data Recovery Wartung und Datenwiederherstellung Maintenance Wartung Data Recovery Daten Wiederherstellung Removing Objects Objekte entfernen Summary Zusammenfassung xiii


15 Chapter 1 Los geht s This chapter will be about getting started with Git. We will begin at the beginning by explaining some background on version control tools, then move on to how to get Git running on your system and finally how to get it setup to start working with. At the end of this chapter you should understand why Git is around, why you should use it and you should be all setup to do so. In diesem Kapitel wird es darum gehen, wie man mit Git loslegen kann. Wir werden erläutern, wozu Versionskontrollsysteme gut sind, wie man Git auf verschiedenen Systemen installieren und konfigurieren kann, so dass man in der Lage ist, mit der Arbeit anzufangen. Am Ende dieses Kapitels solltest Du verstehen, wozu Git gut ist, weshalb Du es verwenden solltest und wie Du damit loslegen kannst. 1.1 Wozu Versionskontrolle? What is version control, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later. For the examples in this book you will use software source code as the files being version controlled, though in reality you can do this with nearly any type of file on a computer. Was ist Versionskontrolle, und warum solltest Du dich dafür interessieren? Versionskontrollsysteme (VCS) protokollieren Änderungen an einer Datei oder einer Anzahl von Dateien über die Zeit hinweg, so dass man zu jedem Zeitpunkt auf Versionen und Änderungen zugreifen kann. Die Beispiele in diesem Buch verwenden Software Quellcode, tatsächlich aber kannst Du Änderungen an praktisch jeder Art von Datei per Versionskontrolle nachverfolgen. If you are a graphic or web designer and want to keep every version of an image or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead. Als ein Grafik- oder Webdesigner zum Beispiel willst Du in der Lage sein, jede Version eines Bildes oder Layouts zurückverfolgen zu können. Es wäre daher sehr ratsam, ein Versionskontrollsystem zu verwenden. Ein solches System erlaubt Dir, einzelne Dateien oder auch ein ganzes Projekt in einen früheren Zustand zurückzuversetzen, nachzuvollziehen, wer zuletzt welche Änderungen vorgenommen hat, die möglicherweise Probleme verursachen, wer eine Änderung ursprünglich vorgenommen hat usw. Ein Versionskontrollsystem für Deine Arbeit zu verwenden, versetzt dich in 1

16 Chapter 1 Los geht s Scott Chacon Pro Git die Lage jederzeit zu einem vorherigen, funktionierenden Zustand zurückzugehen, wenn Du vielleicht Mist gebaut oder aus irgendeinem Grunde Dateien verloren hast. All diese Vorteile erhältst Du für einen nur sehr geringen, zusätzlichen Aufwand Local Version Control Systems Lokale Versionskontrollsysteme Many people s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you re in and accidentally write to the wrong file or copy over files you don t mean to. Viele Leute kontrollieren Versionen ihrer Arbeit, indem sie einfach Dateien in ein anderes Verzeichnis kopieren (wenn sie clever sind: ein Verzeichnis mit einem Zeitstempel im Namen). Diese Vorgehensweise ist üblich, weil sie so einfach ist. Aber sie ist auch unglaublich fehleranfällig. Man vergisst sehr leicht, in welchem Verzeichnis man sich gerade befindet und kopiert die falschen Dateien oder überschreibt Dateien, die man eigentlich nicht überschreiben wollte. To deal with this issue, programmers long ago developed local VCSs that had a simple database that kept all the changes to files under revision control (see Figure 1.1). Um diese Arbeit zu erleichtern und sicherer zu machen, haben Programmierer vor langer Zeit Versionskontrollsysteme entwickelt, die alle Änderungen an allen relevanten Dateien in einer lokalen Datenbank verfolgten (siehe Bild 1-1). Figure 1.1: Local version control diagram Bild 1-1. Diagramm: Lokale Versionskontrolle One of the more popular VCS tools was a system called rcs, which is still distributed with many computers today. Even the popular Mac OS X operating system includes the rcs command when you install the Developer Tools. This tool basically works by keeping patch sets (that is, the differences between files) from one change to another in a special format on disk; it can then re-create what any file looked like at any point in time by adding up all the patches. Eines der populärsten Versionskontrollsysteme war rcs, und es wird heute immer noch mit vielen Computern ausgeliefert. Z.B. umfasst auch das Betriebssystem Mac OS X den Befehl rcs, wenn Du die Developer Tools installierst. Dieser Befehl arbeitet nach dem Prinzip, dass er für jede Änderung einen Patch (d.h. eine Kodierung der Unterschiede, die eine Änderung an einer oder mehreren Dateien umfasst) in einem speziellen Format in einer Datei auf der Festplatte speichert. 2

17 Scott Chacon Pro Git Section 1.1 Wozu Versionskontrolle? Centralized Version Control Systems Zentralisierte Versionskontrollsysteme The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems, such as CVS, Subversion, and Perforce, have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control (see Figure 1.2). Das nächste Problem, mit dem Programmierer sich dann konfrontiert sahen, bestand in der Zusammenarbeit mit anderen: Änderungen an dem gleichen Projekt mussten auf verschiedenen Computern, möglicherweise verschiedenen Betriebssystemen vorgenommen werden können. Um dieses Problem zu lösen, wurden Zentralisierte Versionskontrollsysteme (CVCS) entwickelt. Diese Systeme, beispielsweise CVS, Subversion und Perforce, basieren auf einem zentralen Server, der alle versionierten Dateien verwaltet. Wer an diesen Dateien arbeiten will, kann sie von diesem Server abholen ( check out xxx), auf seinem eigenen Computer bearbeiten und dann wieder auf dem Server abliefern. Diese Art von System war über viele Jahre hinweg der Standard für Versionskontrollsysteme (siehe Bild 1-2). Figure 1.2: Centralized version control diagram Bild 1-2. Diagramm: Zentralisierte Versionskontrollsysteme This setup offers many advantages, especially over local VCSs. For example, everyone knows to a certain degree what everyone else on the project is doing. Administrators have fine-grained control over who can do what; and it s far easier to administer a CVCS than it is to deal with local databases on every client. Dieser Aufbau hat viele Vorteile gegenüber Lokalen Versionskontrollsystemen. Zum Beispiel weiß jeder mehr oder weniger genau darüber Bescheid, was andere, an einem Projekt Beteiligte gerade tun. Administratoren haben die Möglichkeit, detailliert festzulegen, wer was tun kann. Und es ist sehr viel einfacher, ein CVCS zu administrieren als lokalen Datenbanken auf jedem einzelnen Anwenderrechner zu verwalten. However, this setup also has some serious downsides. The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven t been kept, 3

18 Chapter 1 Los geht s Scott Chacon Pro Git you lose absolutely everything the entire history of the project except whatever single snapshots people happen to have on their local machines. Local VCS systems suffer from this same problem whenever you have the entire history of the project in a single place, you risk losing everything. Allerdings hat dieser Aufbau auch einige erhebliche Nachteile. Der offensichtlichste Nachteil ist der Single Point of Failure, den der zentralisierte Server darstellt. Wenn dieser Server für nur eine Stunde nicht verfügbar ist, dann kann in dieser Stunde niemand in irgendeiner Form mit anderen arbeiten oder versionierte Änderungen an den Dateien speichern, an denen sie momentan arbeiten. Wenn die auf dem zentralen Server verwendete Festplatte beschädigt wird und keine Sicherheitskopien erstellt wurden, dann sind all diese Daten unwiederbringlich verloren - die komplette Historie des Projektes, abgesehen natürlich von dem jeweiligen Zustand, den Mitarbeiter gerade zufällig auf ihrem Rechner haben. Lokale Versionskontrollsysteme haben natürlich dasselbe Problem: wenn man die Historie eines Projektes an einer einzigen, zentralen Stelle verwaltet, riskiert man, sie vollständig zu verlieren, wenn irgendetwas an dieser zentralen Stelle ersthaft schief läuft Distributed Version Control Systems This is where Distributed Version Control Systems (DVCSs) step in. In a DVCS (such as Git, Mercurial, Bazaar or Darcs), clients don t just check out the latest snapshot of the files: they fully mirror the repository. Thus if any server dies, and these systems were collaborating via it, any of the client repositories can be copied back up to the server to restore it. Every checkout is really a full backup of all the data (see Figure 1.3). Und an dieser Stelle kommen Distribuierte Versionskontrollsysteme (DVCS) ins Spiel. In einem DVCS (wie z.b. Git, Mercurial, Bazaar oder Darcs) erhalten Anwender nicht einfach den jeweils letzten Snapshot des Projektes von einem Server: sie erhalten statt dessen eine vollständige Kopie des Repositories. Auf diese Weise kann, wenn ein Server beschädigt wird, jedes beliebige Repository von jedem beliebigen Anwenderrechner zurück kopiert und der Server so wieder hergestellt werden. Figure 1.3: Distributed version control diagram Bild 1-3. Diagramm: Distribuierte Versionskontrolle 4

19 Scott Chacon Pro Git Section 1.2 A Short History of Git Furthermore, many of these systems deal pretty well with having several remote repositories they can work with, so you can collaborate with different groups of people in different ways simultaneously within the same project. This allows you to set up several types of workflows that aren t possible in centralized systems, such as hierarchical models. Darüber hinaus können derartige Systeme hervorragend mit verschiedenen externen ( remote ) Repositories umgehen, so dass man mit verschiedenen Gruppen von Leuten simultan in verschiedenen Weisen zusammenarbeiten kann. Das macht es möglich, verschiedene Arten von Arbeitsabläufen (wie Hierarchien) zu integrieren, was mit zentralisierten Systemen nicht möglich ist. 1.2 A Short History of Git 1.3 Die Geschichte von Git As with many great things in life, Git began with a bit of creative destruction and fiery controversy. The Linux kernel is an open source software project of fairly large scope. For most of the lifetime of the Linux kernel maintenance ( ), changes to the software were passed around as patches and archived files. In 2002, the Linux kernel project began using a proprietary DVCS system called BitKeeper. Wie viele großartige Dinge im Leben entstand Git aus kreativem Chaos und hitziger Diskussion. Der Linux Kernel ist ein Open Source Software Projekt von erheblichem Umfang. Während der gesamten Entwicklungszeit des Linux Kernels von 1991 bis 2002 wurden Änderungen an der Software in Form von Patches (d.h. Änderungen an bestehendem Code) und archivierten Dateien herumgereicht began man dann, ein proprietäres DVCS System mit dem Namen Bitkeeper zu verwenden. In 2005, the relationship between the community that developed the Linux kernel and the commercial company that developed BitKeeper broke down, and the tool s free-of-charge status was revoked. This prompted the Linux development community (and in particular Linus Torvalds, the creator of Linux) to develop their own tool based on some of the lessons they learned while using BitKeeper. Some of the goals of the new system were as follows: 2005 ging die Beziehung zwischen der Community, die den Linux Kernel entwickelte, und des kommerziell ausgerichteten Unternehmens, das BitKeeper entwickelte, dann in die Brüche. Die zuvor ausgesprochene Erlaubnis, BitKeeper kostenlos zu verwenden, wurde widerrufen. Dies war für die Linux Entwickler Community der Auslöser dafür, ein eigenes Tool zu entwickeln, das auf den Erfahrungen mit BitKeeper basierte. Ziele des neuen Systems waren unter anderem: Speed Simple design Strong support for non-linear development (thousands of parallel branches) Fully distributed Able to handle large projects like the Linux kernel efficiently (speed and data size) Geschwindigkeit Einfaches Design 5

20 Chapter 1 Los geht s Scott Chacon Pro Git Gute Unterstützung von nicht-linearer Entwicklung (tausende paralleler Branches, d.h. verschiedener Verzweigungen der Versionen) Vollständig distribuiert Fähig, große Projekte wie den Linux Kernel effektiv zu verwalten (Geschwindigkeit und Datenumfang) Since its birth in 2005, Git has evolved and matured to be easy to use and yet retain these initial qualities. It s incredibly fast, it s very efficient with large projects, and it has an incredible branching system for non-linear development (See Chapter 3). Seit seiner Geburt 2005 entwickelte sich Git kontinuierlich weiter und reifte zu einem System heran, das einfach zu bedienen ist, die ursprünglichen Ziele dabei aber weiter beibehält. Es ist unglaublich schnell, äußerst effizient, wenn es um große Projekte geht, und es hat ein fantastisches Branching Konzept für nicht-lineare Entwicklung (mehr dazu in Kapitel 3). 1.4 Git Basics 1.5 Git Grundlagen So, what is Git in a nutshell? This is an important section to absorb, because if you understand what Git is and the fundamentals of how it works, then using Git effectively will probably be much easier for you. As you learn Git, try to clear your mind of the things you may know about other VCSs, such as Subversion and Perforce; doing so will help you avoid subtle confusion when using the tool. Git stores and thinks about information much differently than these other systems, even though the user interface is fairly similar; understanding those differences will help prevent you from becoming confused while using it. Was also ist Git, in kurzen Worten? Es ist wichtig, den folgenden Abschnitt zu verstehen, in dem es um die grundlegenden Konzepte von Git geht. Das wird dich in die Lage versetzen, Git einfacher und effektiver anzuwenden. Versuche dein vorhandenes Wissen über andere Versionskontrollsysteme, wie Subversion oder Perforce, zu ignorieren, während Du Git lernst. Git speichert und konzipiert Information anders als andere Systeme, auch wenn das Interface relativ ähnlich wirkt. Diese Unterschiede zu verstehen wird dir helfen, Verwirrung bei der Anwendung von Git zu vermeiden Snapshots, Not Differences Snapshots, nicht Diffs The major difference between Git and any other VCS (Subversion and friends included) is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. These systems (CVS, Subversion, Perforce, Bazaar, and so on) think of the information they keep as a set of files and the changes made to each file over time, as illustrated in Figure 1.4. Der Hauptunterschied zwischen Git und anderen Versionskontrollsystemen (auch Subversion und vergleichbaren Systemen) besteht in der Art und Weise wie Git Daten betrachtet. Die meisten anderen Systeme speichern Information als eine fortlaufende Liste von Änderungen an Dateien ( Diffs ). Diese Systeme (CVS, Subversion, Perforce, Bazaar usw.) betrachten die Informationen, die sie verwalten, als eine Menge von Dateien und die Änderungen, die über die Zeit hinweg an einzelnen Dateien vorgenommen werden. (Siehe Bild 1-4.) 6

21 Scott Chacon Pro Git Section 1.5 Git Grundlagen Figure 1.4: Other systems tend to store data as changes to a base version of each file. Bild 1-4. Andere Systeme speichern Daten als Änderungen an einzelnen Dateien einer Datenbasis Git doesn t think of or store its data this way. Instead, Git thinks of its data more like a set of snapshots of a mini filesystem. Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot. To be efficient, if files have not changed, Git doesn t store the file again just a link to the previous identical file it has already stored. Git thinks about its data more like Figure 1.5. Git sieht Daten nicht in dieser Weise. Stattdessen betrachtet Git seine Daten eher als eine Reihe von Snapshots eines Mini-Dateisystems. Jedes Mal, wenn Du committest (d.h. den gegenwärtigen Status deines Projektes als eine Version in Git speicherst), sichert Git den Zustand sämtlicher Dateien in diesem Moment ( Snapshot ) und speichert eine Referenz auf diesen Snapshot. Um dies möglichst effizient und schnell tun zu können, kopiert Git unveränderte Dateien nicht, sondern legt lediglich eine Verknüpfung zu der vorherigen Version der Datei an. Git betrachtet Daten also wie in Bild 1-5 dargestellt. Figure 1.5: Git stores data as snapshots of the project over time. Bild 1-5. Git speichert Daten als eine Historie von Snapshots des Projektes. This is an important distinction between Git and nearly all other VCSs. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation. This makes Git more like a mini filesystem with some incredibly powerful tools built on top of it, rather than simply a VCS. We ll explore some of the benefits you gain by thinking of your data this way when we cover Git branching in Chapter 3. Dies ist ein wichtiger Unterschied zwischen Git und praktisch allen anderen Versionskontrollsystemen. In Git wurden daher fast alle Aspekte der Versionskontrolle neu überdacht, die in anderen Systemen mehr oder weniger von ihren jeweiligen Vorgängergeneration übernommen worden waren. Git arbeitet im Großen und Ganzen eher wie ein (mit einigen unglaublich mächtigen Werkezeugen ausgerüstetes) Mini-Dateisystem, als wie ein gängiges Versionskontrollsystem. Auf einige der Vorteile, die es mit sich bringt, Daten in dieser Weise zu betrachten, werden wir in Kapitel 3 eingehen, wenn wir das Git Branching Konzept diskutieren. 7

22 Chapter 1 Los geht s Scott Chacon Pro Git Nearly Every Operation Is Local Fast jede Operation ist lokal Most operations in Git only need local files and resources to operate generally no information is needed from another computer on your network. If you re used to a CVCS where most operations have that network latency overhead, this aspect of Git will make you think that the gods of speed have blessed Git with unworldly powers. Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous. Die meisten Operationen in Git benötigen nur die lokalen Dateien und Ressourcen auf deinem Rechner, um zu funktionieren. D.h. im Allgemeinen werden keine Informationen von einem anderen Rechner im Netzwerk benötigt. Wenn Du mit einem CVCS gearbeitet hast, das für die meisten Operationen einen Netzwerk Latency Overhead (also Wartezeiten, die das Netzwerk benötigt werden) hat, dann wirst Du den Eindruck haben, dass die Götter der Geschwindigkeit Git mit unaussprechlichen Fähigkeiten ausgestattet haben. Weil man die vollständige Historie lokal auf dem Rechner hat, werden die allermeisten Operationen ohne jede Verzögerung ausgeführt und sind sehr schnell. For example, to browse the history of the project, Git doesn t need to go out to the server to get the history and display it for you it simply reads it directly from your local database. This means you see the project history almost instantly. If you want to see the changes introduced between the current version of a file and the file a month ago, Git can look up the file a month ago and do a local difference calculation, instead of having to either ask a remote server to do it or pull an older version of the file from the remote server to do it locally. Um beispielsweise die Historie des Projektes zu durchsuchen, braucht Git sie nicht von einem externen Server zu holen - es liest sie einfach aus der lokalen Datenbank. Das heißt, Du siehst die vollständige Projekthistorie ohne jede Verzögerung. Wenn Du sehen willst, worin sich die aktuelle Version einer Datei von einer Version von vor einem Monat unterscheidet, dann kann Git diese Versionen lokal nachschlagen und ihre Unterschiede lokal bestimmen. Es braucht dazu keinen externen Server - weder um Dateien dort nachzuschlagen, noch um Unterschiede dort bestimmen zu lassen. This also means that there is very little you can t do if you re offline or off VPN. If you get on an airplane or a train and want to do a little work, you can commit happily until you get to a network connection to upload. If you go home and can t get your VPN client working properly, you can still work. In many other systems, doing so is either impossible or painful. In Perforce, for example, you can t do much when you aren t connected to the server; and in Subversion and CVS, you can edit files, but you can t commit changes to your database (because your database is offline). This may not seem like a huge deal, but you may be surprised what a big difference it can make. Dies bedeutet natürlich außerdem, dass es fast nichts gibt, was Du nicht tun kannst, bloß weil Du gerade offline bist oder keinen Zugriff auf ein VPN hast. Wenn Du im Flugzeug oder Zug ein wenig arbeiten willst, kannst Du problemlos deine Arbeit committen und deine Arbeit erst auf den Server pushen (hochladen), wenn Du wieder mit einem Netzwerk verbunden bist. Wenn Du zu Hause bist aber nicht auf das VPN zugreifen kannst, kannst Du dennoch arbeiten. Perforce z.b. erlaubt dir dagegen nicht sonderlich viel zu tun, solange Du nicht mit dem Server verbunden bist. Und in Subversion und CVS kannst Du Dateien zwar ändern, die Änderungen aber nicht in der Datenbank sichern (weil die Datenbank offline ist). Das mag auf den ersten Blick nicht nach einem großen Problem aussehen, aber Du wirst überrascht sein, was für einen großen Unterschied das ausmachen kann. 8

23 Scott Chacon Pro Git Section 1.5 Git Grundlagen Git Has Integrity Git stellt Integrität sicher Everything in Git is check-summed before it is stored and is then referred to by that checksum. This means it s impossible to change the contents of any file or directory without Git knowing about it. This functionality is built into Git at the lowest levels and is integral to its philosophy. You can t lose information in transit or get file corruption without Git being able to detect it. In Git werden Änderungen in Checksummen umgerechnet, bevor sie gespeichert werden. Anschließend werden sie mit dieser Checksumme referenziert. Das macht es unmöglich, dass sich die Inhalte von Dateien oder Verzeichnissen ändern, ohne dass Git das mitbekommt. Git basiert auf dieser Funktionalität und sie ist ein integraler Teil von Gits Philosophie. Man kann Informationen deshalb z.b. nicht während der Übermittlung verlieren oder unwissentlich beschädigte Dateien verwenden, ohne dass Git in der Lage wäre, dies festzustellen. The mechanism that Git uses for this checksumming is called a SHA-1 hash. This is a 40- character string composed of hexadecimal characters (0 9 and a f) and calculated based on the contents of a file or directory structure in Git. A SHA-1 hash looks something like this: Der Mechanismus, den Git verwendet, um diese Checksummen zu erstellen, heißt SHA-1 Hash. Eine solche Checksumme ist eine 40 Zeichen lange Zeichenkette, die aus hexadezimalen Zeichen besteht und diese wird von Git aus den Inhalten einer Datei oder Verzeichnisstruktur kalkuliert. Ein SHA-1 Hash sieht wie folgt aus: 24b9da aa493b52f8696cd6d3b b9da aa493b52f8696cd6d3b00373 You will see these hash values all over the place in Git because it uses them so much. In fact, Git stores everything not by file name but in the Git database addressable by the hash value of its contents. Dir werden solche Hash Werte überall in Git begegnen, weil es sie so ausgiebig benutzt. Tatsächlich speichert und referenziert Git Informationen über Dateien in der Datenbank nicht nach ihren Dateinamen sondern nach den Hash Werten ihrer Inhalte Git Generally Only Adds Data Git verwaltet fast ausschließlich Daten When you do actions in Git, nearly all of them only add data to the Git database. It is very difficult to get the system to do anything that is not undoable or to make it erase data in any way. As in any VCS, you can lose or mess up changes you haven t committed yet; but after you commit a snapshot into Git, it is very difficult to lose, especially if you regularly push your database to another repository. Fast alle Operationen, die Du in der täglichen Arbeit mit Git verwendest, fügen Daten jeweils nur zur internen Git Datenbank hinzu. Deshalb ist es sehr schwer, das System dazu zu bewegen, irgendetwas zu tun, das nicht wieder rückgängig zu machen ist, oder dazu, Daten in irgendeiner Form zu löschen. In jedem anderen VCS ist es leicht, Änderungen, die man noch nicht gespeichert hat, zu verlieren oder unbrauchbar zu machen. In Git dagegen ist es schwierig, einen einmal gespeicherten Snapshot zu verlieren, insbesondere wenn man regelmäßig in ein anderes Repository pusht. 9

24 Chapter 1 Los geht s Scott Chacon Pro Git This makes using Git a joy because we know we can experiment without the danger of severely screwing things up. For a more in-depth look at how Git stores its data and how you can recover data that seems lost, see Under the Covers in Chapter 9. U.a. deshalb macht es so viel Spaß, mit Git zu arbeiten. Man kann mit Änderungen experimentieren, ohne befürchten zu müssen, irgendetwas zu zerstören oder durcheinander zu bringen. Einen tieferen Einblick in die Art, wie Git Daten speichert und wie man Daten, die scheinbar verloren sind, wieder herstellen kann, wird Kapitel 9 gewähren The Three States Die drei Zustände Now, pay attention. This is the main thing to remember about Git if you want the rest of your learning process to go smoothly. Git has three main states that your files can reside in: committed, modified, and staged. Committed means that the data is safely stored in your local database. Modified means that you have changed the file but have not committed it to your database yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot. Jetzt aufgepasst. Es folgt die wichtigste Information, die Du dir merken mußt, wenn Du Git lernen und Fallstricke vermeiden willst. Git definiert drei Haupt-Zustände, in denen sich eine Datei befinden kann: committed, modified ( geändert ) und staged ( vorgemerkt ). Committed bedeutet, dass die Daten in der lokalen Datenbank gesichert sind. Modified bedeutet, dass die Datei geändert, diese Änderung aber noch nicht committed wurde. Staged bedeutet, dass Du eine geänderte Datei in ihrem gegenwärtigen Zustand für den nächsten Commit vorgemerkt hast. This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area. Das führt uns zu den drei Hauptbereichen eines Git Projektes: das Git Verzeichnis, das Arbeitsverzeichnis und die Staging Area. Figure 1.6: Working directory, staging area, and git directory Bild 1-6. Arbeitsverzeichnis, Staging Area (xxx) und Git Verzeichnis The Git directory is where Git stores the metadata and object database for your project. This is 10

25 Scott Chacon Pro Git Section 1.6 Installing Git the most important part of Git, and it is what is copied when you clone a repository from another computer. Das Git Verzeichnis ist der Ort, an dem Git Metadaten und die lokale Datenbank für dein Projekt speichert. Dies ist der wichtigste Teil von Git, und dieser Teil wird kopiert, wenn Du ein Repository von einem anderen Rechner klonst. The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. Dein Arbeitsverzeichnis ist ein Checkout ( Abbild xxx) einer spezifischen Version des Projektes. Diese Dateien werden aus der komprimierten Datenbank geholt und auf der Festplatte in einer Form gespeichert, die Du bearbeiten und modifizieren kannst. The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It s sometimes referred to as the index, but it s becoming standard to refer to it as the staging area. Die Staging Area ist einfach eine Datei (normalerweise im Git Verzeichnis), in der vorgemerkt wird, welche Änderungen dein nächster Commit umfassen soll. Sie wird manchmal auch als Index bezeichnet, aber der Begriff Staging Area ist der gängigere. The basic Git workflow goes something like this: Der grundlegend Git Arbeitsprozess sieht in etwa so aus: 1. You modify files in your working directory. 2. You stage the files, adding snapshots of them to your staging area. 3. You do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory. 4. Du bearbeitest Dateien in deinem Arbeitsverzeichnis. 5. Du markierst Dateien für den nächsten Commit, indem Du Snapshots zur Staging Area hinzufügst. 6. Du legst den Commit an, wodurch die in der Staging Area vorgemerkten Snapshots dauerhaft im Git Verzeichnis (d.h. der lokalen Datenbank) gespeichert werden. If a particular version of a file is in the git directory, it s considered committed. If it s modified but has been added to the staging area, it is staged. And if it was changed since it was checked out but has not been staged, it is modified. In Chapter 2, you ll learn more about these states and how you can either take advantage of them or skip the staged part entirely. Wenn eine bestimmte Version einer Datei im Git Verzeichnis liegt, gilt sie als committed. Wenn sie geändert und in der Staging Area vorgemerkt ist, gilt sie als staged. Und wenn sie geändert, aber noch nicht zur Staging Area hinzugefügt wurde, gilt sie als modified. In Kapitel 2 wirst Du mehr über diese Zustände lernen und darüber, wie Du sie sinnvoll einsetzen und wie Du den Zwischenschritt der Staging Area auch einfach überspringen kannst. 1.6 Installing Git 1.7 Git Installieren Let s get into using some Git. First things first you have to install it. You can get it a number of ways; the two major ones are to install it from source or to install an existing package for your 11

26 Chapter 1 Los geht s Scott Chacon Pro Git platform. Laß uns damit anfangen, Git tatsächlich zu verwenden. Der erste Schritt besteht natürlich darin, Git zu installieren und das kann, wie üblich, auf unterschiedliche Weisen geschehen. Die beiden wichtigsten bestehen darin, entweder den Quellcode herunterzuladen und selbst zu kompilieren oder ein fertiges Paket für dein Betriebssystem zu installieren Installing from Source Vom Quellcode aus installieren If you can, it s generally useful to install Git from source, because you ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you re on a very up-to-date distro or are using backports, installing from source may be the best bet. Wenn es dir möglich ist, empfehlen wir, Git vom Quellcode aus zu installieren, weil Du die jeweils neueste Version erhältst. In der Regel bringt jede Version nützliche Verbesserungen (z.b. am Interface), so dass es sich lohnt die jeweils neueste Version zu verwenden - sofern Du natürlich damit klarkommst, Software aus dem Quellcode zu kompilieren. Viele Linux Distributionen umfassen sehr alte Git Versionen. Wenn Du also keine sehr aktuelle Distribution oder Backports (xxx) verwendest, empfehlen wir, diesen Weg in Erwägung ziehen. To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you re on a system that has yum (such as Fedora) or apt-get (such as a Debian based system), you can use one of these commands to install all of the dependencies: Um Git zu installieren, benötigst Du die folgenden Bibliotheken, die von Git verwendet werden: curl, zlib, openssl, expat und libiconv. Wenn Dir auf deinem System yum (z.b. auf Fedora) oder aptget (z.b. auf Debian-basierten Systemen) zur Verfügung steht, kannst Du einen der folgenden Befehle verwenden, um diese Abhängigkeiten zu installieren: $ yum install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel $ apt-get install curl-devel expat-devel gettext-devel \ openssl-devel zlib-devel When you have all the necessary dependencies, you can go ahead and grab the latest snapshot from the Git web site: Nachdem Du die genannten Bibliotheken installiert hast, besorge dir die aktuelle Version des Git Quellcodes von der Git Webseite: Then, compile and install: Danach kannst Du dann Git kompilieren und installieren: $ tar -zxf git tar.gz $ cd git

27 Scott Chacon Pro Git Section 1.7 Git Installieren $ make prefix=/usr/local all $ sudo make prefix=/usr/local install After this is done, you can also get Git via Git itself for updates: Von nun an kannst Du Git mit Hilfe von Git selbst aktualisieren: $ git clone git:// Installing on Linux Installation unter Linux If you want to install Git on Linux via a binary installer, you can generally do so through the basic package-management tool that comes with your distribution. If you re on Fedora, you can use yum: Wenn Du Git unter Linux mit einem Installationsprogramm installieren willst, kannst Du das normalerweise mit dem Paketmanager tun, der von deinem Betriebssystem verwendet wird. Unter Fedora zum Beispiel kannst Du yum verwenden: $ yum install git-core Or if you re on a Debian-based distribution like Ubuntu, try apt-get: Auf einem Debian-basierten System wie Ubuntu steht dir apt-get zur Verfügung: $ apt-get install git-core Installing on Mac Installation unter Mac OS X There are two easy ways to install Git on a Mac. The easiest is to use the graphical Git installer, which you can download from the Google Code page (see Figure 1.7): Auf einem Mac kann man Git auf zwei Arten installieren. Der einfachste ist, das grafische Git Installationsprogramm zu verwenden, den man von der Google Code Webseite herunterladen kann (siehe Bild 1-7) The other major way is to install Git via MacPorts ( If you have Mac- Ports installed, install Git via Die andere Möglichkeit ist, Git via MacPorts ( zu installieren. Wenn Du MacPorts auf deinem System hast, installiert der folgende Befehl Git: 13

28 Chapter 1 Los geht s Scott Chacon Pro Git Figure 1.7: Git OS X installer $ sudo port install git-core +svn +doc +bash_completion +gitweb You don t have to add all the extras, but you ll probably want to include +svn in case you ever have to use Git with Subversion repositories (see Chapter 8). Du brauchst die optionalen Features natürlich nicht mit zu installieren, aber es macht Sinn +svn zu verwenden, falls Du jemals Git mit einem Subversion Repository verwenden willst Installing on Windows Installation unter Windows Installing Git on Windows is very easy. The msysgit project has one of the easier installation procedures. Simply download the installer exe file from the Google Code page, and run it: Das msysgit Projekt macht die Installation von Git unter Windows sehr einfach. Lade einfach das Installationsprogramm für Windows von der Google Code Webseite herunter und führe es aus: After it s installed, you have both a command-line version (including an SSH client that will come in handy later) and the standard GUI. Danach hast Du sowohl eine Kommandozeilenversion (inklusive eines SSH Clients, der sich später noch als nützlich erweisen wird) als auch die Standard GUI installiert. 1.8 First-Time Git Setup 1.9 Git konfigurieren Now that you have Git on your system, you ll want to do a few things to customize your Git environment. You should have to do these things only once; they ll stick around between upgrades. You can also change them at any time by running through the commands again. Nachdem Du jetzt Git auf deinem System installiert hast, solltest Du deine Git Konfiguration anpassen. Das brauchst Du nur einmal zu tun, die Konfiguration bleibt auch bestehen, wenn Du Git 14

29 Scott Chacon Pro Git Section 1.9 Git konfigurieren auf eine neuere Version aktualisierst. Du kannst sie jederzeit ändern, indem Du die folgenden Befehle einfach noch einmal ausführst. Git comes with a tool called git config that lets you get and set configuration variables that control all aspects of how Git looks and operates. These variables can be stored in three different places: Git umfasst das Werkzeug git config, das dir erlaubt, Konfigurationswerte zu verändern. Auf diese Weise kannst Du anpassen, wie Git aussieht und arbeitet. Diese Werte sind an drei verschiedenen Orten gespeichert: /etc/gitconfig file: Contains values for every user on the system and all their repositories. If you pass the option--system to git config, it reads and writes from this file specifically. ~/.gitconfig file: Specific to your user. You can make Git read and write to this file specifically by passing the --global option. config file in the git directory (that is,.git/config) of whatever repository you re currently using: Specific to that single repository. Each level overrides values in the previous level, so values in.git/config trump those in /etc/gitconfig. Die Datei /etc/gitconfig enthält Werte, die für jeden Anwender des Systems und all ihre Projekte gelten. Wenn Du git config mit der Option --system verwendest, wird diese Datei verwendet. Die Werte in der Datei ~/.gitconfig gelten ausschließlich für dich und all deine Projekte. Wenn Du git config mit der Option --global verwendest, wird diese Datei verwendet. Die Datei.git/config im Git Verzeichnis eines Projektes enthält Werte, die nur für das jeweilige Projekt gelten. Diese Dateien überschreiben Werte aus den jeweils vorhergehenden Dateien in dieser Reihenfolge. D.h. Werte in beispielsweise.git/config überschreiben diejenigen in /etc/gitconfig. On Windows systems, Git looks for the.gitconfig file in the $HOME directory (C:\Documents and Settings\$USER for most people). It also still looks for /etc/gitconfig, although it s relative to the MSys root, which is wherever you decide to install Git on your Windows system when you run the installer. Auf Windows Systemen sucht Git nach der.gitconfig Datei im $HOME Verzeichnis (für die meisten Leute ist das das Verzeichnis C:\Dokumente und Einstellungen\$USER). Git sucht außerdem auch nach dem Verzeichnis /etc/gitconfig, aber es sucht relativ demjenigen Verzeichnis, in dem Du Git mit Hilfe des Installers installiert hast Your Identity Deine Identität The first thing you should do when you install Git is to set your user name and address. This is important because every Git commit uses this information, and it s immutably baked into the commits you pass around: Nachdem Du Git installiert hast, solltest Du als erstes deinen Namen und deine Adresse konfigurieren. Das ist wichtig, weil Git diese Information für jeden Commit verwendet, den Du anlegst, und sie ist unveränderlich in deine Commits eingebaut (xxx): 15

30 Chapter 1 Los geht s Scott Chacon Pro Git $ git config --global "John Doe" $ git config --global user. Again, you need to do this only once if you pass the --global option, because then Git will always use that information for anything you do on that system. If you want to override this with a different name or address for specific projects, you can run the command without the -- global option when you re in that project. Du brauchst diese Konfiguration, wie schon erwähnt, nur einmal vorzunehmen, wenn Du die --global Option verwendest, weil Git diese Information dann für all deine Projekte verwenden wird. Wenn Du sie für ein spezielles Projekt mit einem anderen Namen oder einer anderen Adresse überschreiben willst, kannst Du dazu den Befehl ohne die --global Option innerhalb dieses Projektes ausführen Your Editor Dein Editor Now that your identity is set up, you can configure the default text editor that will be used when Git needs you to type in a message. By default, Git uses your system s default editor, which is generally Vi or Vim. If you want to use a different text editor, such as Emacs, you can do the following: Nachdem Du deine Identität jetzt konfiguriert hast, kannst Du einstellen, welchen Texteditor Git in Situationen verwenden soll, in denen Du eine Nachricht eingeben mußt. Normalerweise verwendet Git den Standard-Texteditor deines Systems - das ist üblicherweise Vi oder Vim. Wenn Du einen anderen Texteditor, z.b. Emacs, verwenden willst, kannst Du das wie folgt festlegen: $ git config --global core.editor emacs Your Diff Tool Dein Diff Programm Another useful option you may want to configure is the default diff tool to use to resolve merge conflicts. Say you want to use vimdiff: Eine andere nützliche Einstellung, die Du möglicherweise vornehmen willst, ist welches Diff Programm Git verwendet. Mit diesem Programm kannst Du Konflikte auflösen, die während der Arbeit mit Git manchmal auftreten. Wenn Du beispielsweise vimdiff verwenden willst, kannst Du das so festlegen: $ git config --global merge.tool vimdiff Git accepts kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff as valid merge tools. You can also set up a custom tool; see Chapter 7 for more information about doing that. 16

31 Scott Chacon Pro Git Section 1.10 Getting Help Git kann von Hause aus mit den folgenden Diff Programmen arbeiten: kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff. Außerdem kannst Du ein eigenes Programm aufsetzen. Wir werden in Kapitel 7 darauf eingehen, wie das geht Checking Your Settings Deine Einstellungen überprüfen If you want to check your settings, you can use the git config --list command to list all the settings Git can find at that point: Wenn Du deine Einstellungen überprüfen willst, kannst Du mit dem Befehl git config --list alle Einstellungen anzuzeigen, die Git an dieser Stelle (z.b. innerhalb eines bestimmten Projektes) bekannt sind: $ git config --list Chacon color.status=auto color.branch=auto color.interactive=auto color.diff=auto... You may see keys more than once, because Git reads the same key from different files (/etc/ gitconfig and ~/.gitconfig, for example). In this case, Git uses the last value for each unique key it sees. Manche Variablen werden möglicherweise mehrfach aufgelistet, weil Git dieselbe Variable in verschiedenen Dateien (z.b. /etc/gitconfig und ~/.gitconfig) findet. In diesem Fall verwendet Git dann den jeweils zuletzt aufgelisteten Wert. You can also check what Git thinks a specific key s value is by typing git config key: Außerdem kannst Du mit dem Befehl git config key prüfen, welchen Wert Git für einen bestimmten Variablennamen verwendet: $ git config Scott Chacon 1.10 Getting Help 1.11 Hilfe finden If you ever need help while using Git, there are three ways to get the manual page (manpage) help for any of the Git commands: Falls Du jemals Hilfe in der Anwendung von Git benötigst, gibt es drei Möglichkeiten, die entsprechende Seite aus der Dokumentation (manpage) für jeden Git Befehl anzuzeigen: 17

32 Chapter 1 Los geht s Scott Chacon Pro Git $ git help <verb> $ git <verb> --help $ man git-<verb> For example, you can get the manpage help for the config command by running Beispielsweise erhältst Du die Hilfeseite für den git config Befehl so: $ git help config These commands are nice because you can access them anywhere, even offline. If the manpages and this book aren t enough and you need in-person help, you can try the #git or #github channel on the Freenode IRC server ( These channels are regularly filled with hundreds of people who are all very knowledgeable about Git and are often willing to help. Die manpage Dokumentation ist nützlich, weil Du sie jederzeit anzeigen kannst, auch wenn Du offline bist. Wenn dir die manpages und dieses Buch nicht ausreichen, kannst Du deine Fragen auch in den Chaträumen #git oder #github auf dem Freenode IRC Server ( stellen. Diese Räume sind in der Regel sehr gut besucht. Normalerweise findet sich unter den hunderten von Anwendern, die oft sehr viel Erfahrung mit Git haben, irgendjemand, der deine Fragen gern beantwortet Summary You should have a basic understanding of what Git is and how it s different from the CVCS you may have been using. You should also now have a working version of Git on your system that s set up with your personal identity. It s now time to learn some Git basics. Du solltest jetzt ein basales Verständnis davon haben, was Git ist und wie es sich von anderen CVCS unterscheidet, die Du möglicherweise schon verwendet hast. Du solltest außerdem eine funktionierende Git Version auf deinem Rechner installiert und konfiguriert haben. Jetzt wird es Zeit, einige Git Grundlagen zu besprechen. 18

33 Chapter 2 Git Basics 19


35 Chapter 3 Git Grundlagen If you can read only one chapter to get going with Git, this is it. This chapter covers every basic command you need to do the vast majority of the things you ll eventually spend your time doing with Git. By the end of the chapter, you should be able to configure and initialize a repository, begin and stop tracking files, and stage and commit changes. We ll also show you how to set up Git to ignore certain files and file patterns, how to undo mistakes quickly and easily, how to browse the history of your project and view changes between commits, and how to push and pull from remote repositories. Wenn Du nur ein einziges Kapitel aus diesem Buch lesen willst, um mit Git loslegen zu können, dann lies dieses hier. Wir werden hier auf diejenigen grundlegenden Git Befehle eingehen, die du für den allergrößten Teil deiner täglichen Arbeit mit Git brauchst. Am Ende des Kapitels solltest du in der Lage sein, ein neues Repository anzulegen und zu konfigurieren, Dateien zur Versionskontrolle hinzuzufügen und wieder aus ihr zu entfernen, Änderungen in der Staging Area für einen Commit vorzumerken und schließlich einen Commit durchzuführen. Wir werden außerdem besprechen, wie du Git so konfigurieren kannst, dass es bestimmte Dateien und Dateimuster ignoriert, wie du Fehler schnell und einfach rückgängig machen, wie du die Historie deines Projektes durchsuchen und Änderungen zwischen bestimmten Commits nachschlagen, und wie du in externe Repositories heraufund von dort herunterladen kannst. 3.1 Getting a Git Repository 3.2 Ein Git Repository anlegen You can get a Git project using two main approaches. The first takes an existing project or directory and imports it into Git. The second clones an existing Git repository from another server. Es gibt grundsätzlich zwei Möglichkeiten, ein Git Repository auf dem eigenen Rechner anzulegen. Erstens kann man ein existierendes Projekt oder Verzeichnis als ein neues Git Repository initialisieren. Zweitens kann man ein existierendes Repository von einem anderen Rechner, der als Server fungiert, auf den eigenen Rechner klonen. 21

36 Chapter 3 Git Grundlagen Scott Chacon Pro Git Initializing a Repository in an Existing Directory Ein existierendes Verzeichnis als Git Repository initialisieren If you re starting to track an existing project in Git, you need to go to the project s directory and type Wenn du künftige Änderungen an einem bestehenden Projekt auf Deinem Rechner mit Git versionieren und nachverfolgen willst, kannst du dazu einfach in das jeweilige Verzeichnis gehen und diesen Befehl ausführen: $ git init This creates a new subdirectory named.git that contains all of your necessary repository files a Git repository skeleton. At this point, nothing in your project is tracked yet. (See Chapter 9 for more information about exactly what files are contained in the.git directory you just created.) Das erzeugt ein Git Verzeichnis.git, in dem alle relevanten Git Repository Dateien enthalten sind, also ein Git Repository Grundgerüst. Zu diesem Zeitpunkt werden dann noch keine Dateien versioniert. (In Kapitel 9 werden wir genauer darauf eingehen, welche Dateien im.git Verzeichnis gerade erzeugt wurden.) If you want to start version-controlling existing files (as opposed to an empty directory), you should probably begin tracking those files and do an initial commit. You can accomplish that with a few git add commands that specify the files you want to track, followed by a commit: Wenn in deinem Projekt bereits Dateien vorhanden sind (und es sich nicht nur um ein leeres Verzeichnis handelt), willst du diese vermutlich zur Versionskontrolle hinzufügen, damit Änderungen daran künftig nachverfolgbar sind. Dazu kannst du die folgenden Git Befehle ausführen, die Dateien zur Versionskontrolle hinzufügen und anschließend einen ersten Commit anlegen: $ git add *.c $ git add README $ git commit m 'initial project version' We ll go over what these commands do in just a minute. At this point, you have a Git repository with tracked files and an initial commit. Wir werden gleich noch einmal genauer auf diese Befehle eingehen. Im Moment ist nur wichtig zu verstehen, dass du jetzt ein neues, funktionierendes Git Repository erzeugt und einen ersten Commit angelegt hast Cloning an Existing Repository Ein existierendes Repository klonen If you want to get a copy of an existing Git repository for example, a project you d like to contribute to the command you need is git clone. If you re familiar with other VCS systems such as Subversion, you ll notice that the command is clone and not checkout. This is an important distinction Git receives a copy of nearly all data that the server has. Every version of every file for the history 22

37 Scott Chacon Pro Git Section 3.2 Ein Git Repository anlegen of the project is pulled down when you run git clone. In fact, if your server disk gets corrupted, you can use any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there see Chapter 4 for more details). Wenn du eine Kopie eines existierenden Git Repositories anlegen willst - z.b. um an einem existierenden Projekt mitzuarbeiten - dann kannst du dazu den Befehl git clone verwenden. Wenn du schon mit anderen VCS Sytemen wie Subversion gearbeitet hast, wird dir auffallen, dass der Befehl clone heißt und nicht checkout. Dies ist ein wichtiger Unterschied, den du verstehen solltest. Git lädt eine Kopie praktisch sämtlicher Daten, die sich in dem geklonten Repository befinden, auf deinen Rechner. Mit git clone wird jede einzelne Version jeder einzelnen Datei in der Historie des Repositories heruntergeladen. Wenn ein Repository auf einem Server einmal beschädigt wird (z.b. weil die Festplatte beschädigt wird), kann man tatsächlich jeden beliebigen Klon des Repositories verwenden, um das Repository auf dem Server wieder in dem Zustand wieder herzustellen, in dem es sich befand, als es geklont wurde. (Es kann passieren, dass man einige Hooks (xxx) auf dem Server verliert, aber alle versionierten Daten bleiben erhalten. In Kapitel 4 gehen wir darauf noch einmal genauer ein.) You clone a repository with git clone [url]. For example, if you want to clone the Ruby Git library called Grit, you can do so like this: Du kannst ein Repository mit dem Befehl git clone [url] klonen. Um beispielsweise das Repository der Ruby Git Bibliothek Grit zu klonen, führst du den folgenden Befehl aus: $ git clone git:// That creates a directory named grit, initializes a.git directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. If you go into the new grit directory, you ll see the project files in there, ready to be worked on or used. If you want to clone the repository into a directory named something other than grit, you can specify that as the next command-line option: Git legt dann ein Verzeichnis grit an, initialisiert ein.git Verzeichnis darin, lädt alle Daten für das Repository herunter, und checkt eine Arbeitskopie der letzten Version aus. Wenn Du in das neue grit Verzeichnis schaust, findest du dort die in diesem Projekt enthaltenen Dateien und kannst sie benutzen oder bearbeiten. Wenn du das Repository in ein Verzeichnis mit einem anderen Namen als grit klonen willst, kannst du das wie folgt angeben: $ git clone git:// mygrit That command does the same thing as the previous one, but the target directory is called mygrit. Dieser Befehl tut das gleiche wie der vorhergehende, aber das Zielverzeichnis ist diesmal mygrit. Git has a number of different transfer protocols you can use. The previous example uses the git:// protocol, but you may also see http(s):// or which uses the SSH transfer protocol. Chapter 4 will introduce all of the available options the server can set up to access your Git repository and the pros and cons of each. Git unterstützt eine Reihe unterschiedlicher Übertragungsprotokolle, die du verwenden kannst. Das vorhergehende Beispiel verwendet das git:// Protokoll, aber du wirst auch http(s):// 23

38 Chapter 3 Git Grundlagen Scott Chacon Pro Git oder finden, die das SSH Protokoll verwenden. In Kapitel 4 gehen wir auf die verschiedenen Optionen (und deren Vor- und Nachteile) ein, die ein Server hat, um Zugriff auf ein Git Repository zu erlauben. 3.3 Recording Changes to the Repository 3.4 Änderungen am Repository nachverfolgen You have a bona fide Git repository and a checkout or working copy of the files for that project. You need to make some changes and commit snapshots of those changes into your repository each time the project reaches a state you want to record. Du hast jetzt ein vollständiges und funktionierendes Git Repository und ein Checkout (eine Arbeitskopie) der Dateien in diesem Projekt. Du willst jetzt Änderungen an diesen Dateien vornehmen und Snapshots (Commits) der Dateien immer dann anlegen, wenn das Projekt einen Zustand erreicht, den du aufzeichnen willst. Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot; they can be unmodified, modified, or staged. Untracked files are everything else - any files in your working directory that were not in your last snapshot and are not in your staging area. When you first clone a repository, all of your files will be tracked and unmodified because you just checked them out and haven t edited anything. Jede Datei in deinem Arbeitsverzeichnis kann entweder unter Versionskontrolle befinden ( versioniert sein ) oder nicht. Alle Dateien, die sich im letzten Snapshot (Commit) befanden, stehen unter Versionskontrolle. Sie können entweder unverändert, modifiziert oder für den nächsten Commit markiert sein. Alle anderen Dateien in deinem Arbeitsverzeichnis dagegen sind nicht versioniert: das sind all diejenigen Dateien, die nicht schon im letzten Snapshot enthalten waren und die sich nicht in der Staging Area befinden (xxx new, staged files are being tracked? xxx). Wenn Du ein Repository gerade geklont hast, sind alle Dateien versioniert und unverändert - du hast sie gerade ausgecheckt aber noch nichts verändert. As you edit files, Git sees them as modified, because you ve changed them since your last commit. You stage these modified files and then commit all your staged changes, and the cycle repeats. This lifecycle is illustrated in Figure 2.1. Sobald du versionierte Dateien bearbeitest, wird Git sie als modifiziert erkennen, weil du sie seit dem letzten Commit geändert hast. Du merkst diese geänderten Dateien für den nächsten Commit vor (d.h. du fügst sie zur Staging Area hinzu), legst aus allen markierten Änderungen einen Commit an und der Vorgang beginnt von vorn. Bild 2-1 stellt diesen Zyklus dar: Checking the Status of Your Files Den Zustand deiner Dateien prüfen The main tool you use to determine which files are in which state is the git status command. If you run this command directly after a clone, you should see something like this: Das wichtigste Hilfsmittel, um den Zustand zu überprüfen, in dem sich die Dateien in deinem Repository gerade befinden, ist der Befehl git status. Wenn du diesen Befehl ausführst, unmittelbar nachdem du ein Repository geklont hast, solltest du in etwa Folgendes sehen: 24

39 Scott Chacon Pro Git Section 3.4 Änderungen am Repository nachverfolgen Figure 3.1: The lifecycle of the status of your files Bild 2-1. Zyklus der Grundzustände deiner Dateien $ git status # On branch master nothing to commit (working directory clean) This means you have a clean working directory in other words, there are no tracked and modified files. Git also doesn t see any untracked files, or they would be listed here. Finally, the command tells you which branch you re on. For now, that is always master, which is the default; you won t worry about it here. The next chapter will go over branches and references in detail. Man sagt auch, du hast ein sauberes Arbeitsverzeichnis. Mit anderen Worten, es gibt keine Dateien, die unter Versionskontrolle stehen und seit dem letzten Commit geändert wurden - andernfalls würden sie hier aufgelistet werden. Außerdem teilt dir der Befehl mit, in welchem Branch du dich befindest. In diesem Beispiel ist dies der Standard Branch master. Mach dir darüber im Moment keine Gedanken, wir werden im nächsten Kapitel auf Branches und Referenzen detailliert eingehen. Let s say you add a new file to your project, a simple README file. If the file didn t exist before, and you run git status, you see your untracked file like so: Sagen wir du fügst eine neue README Datei zu deinem Projekt hinzu. Wenn die Datei zuvor nicht existiert hat und du jetzt git status ausführst, zeigt Git die bisher nicht versionierte Datei wie folgt an: $ vim README $ git status # On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) # # README nothing added to commit but untracked files present (use "git add" to track) You can see that your new README file is untracked, because it s under the Untracked files heading in your status output. Untracked basically means that Git sees a file you didn t have in the previous snapshot (commit); Git won t start including it in your commit snapshots until you explicitly 25

40 Chapter 3 Git Grundlagen Scott Chacon Pro Git tell it to do so. It does this so you don t accidentally begin including generated binary files or other files that you did not mean to include. You do want to start including README, so let s start tracking the file. Daran, dass deine neue README Datei in der Sektion Untracked files aufgelistet wird, siehst du, dass sie noch nicht versioniert ist, oder mit anderen Worten, dass Git die Datei noch nicht aus dem letzten Snapshot (Commit) kennt. Git nimmt eine solche Datei nicht von sich aus in die Versionskontrolle auf, sondern du mußt das ausdrücklich anfordern. Der Grund dafür ist, dass Git nicht einfache alle möglichen binären Dateien oder anderen Dateien hinzufügen soll, die du nicht in deinem Repository haben willst. Du willst jetzt aber deine neues README Datei zur Versionskontrolle hinzufügen, also mußt du das explit tun Tracking New Files Neue Dateien zur Versionskontrolle hinzufügen In order to begin tracking a new file, you use the command git add. To begin tracking the README file, you can run this: Um eine neue Datei zur Versionskontrolle hinzuzufügen, verwendest du den Befehl git add. Für deine neue README Datei kannst du ihn wie folgt ausführen: $ git add README If you run your status command again, you can see that your README file is now tracked and staged: Wenn du den git status Befehl erneut ausführst, siehst du, dass sich deine README Datei jetzt unter Versionskontrolle befindet und für den nächsten Commit vorgemerkt ist: $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # You can tell that it s staged because it s under the Changes to be committed heading. If you commit at this point, the version of the file at the time you ran git add is what will be in the historical snapshot. You may recall that when you ran git init earlier, you then ran git add (files) that was to begin tracking files in your directory. The git add command takes a path name for either a file or a directory; if it s a directory, the command adds all the files in that directory recursively. Dass die Datei für den nächsten Commit vorgemerkt ist, siehst du daran, dass sie in der Sektion Changes to be committed aufgelistet ist. Wenn du jetzt einen Commit anlegst, wird der Snapshot den Zustand der Datei beinhalten, in dem du den Befehl git add ausgeführt hast. Du erinnerst dich daran, dass du, als du vorhin git init ausgeführt hast, anschließend git add ausgeführt hast: an dieser Stelle hast du die Dateien in deinem Verzeichnis der Versionskontrolle hinzugefügt. Der 26

41 Scott Chacon Pro Git Section 3.4 Änderungen am Repository nachverfolgen git add Befehl akzeptiert einen Pfadnamen einer Datei oder eines Verzeichnisses. Wenn du ein Verzeichnis angibst, fügt git add alle Dateien in diesem Verzeichnis und allen Unterverzeichnissen rekursiv hinzu Staging Modified Files Let s change a file that was already tracked. If you change a previously tracked file called benchmarks.rb and then run your status command again, you get something that looks like this: Ändern wir also eine Datei, die sich in Versionskontrolle befindet. Wenn du eine bereits versionierte Datei benchmarks.rb änderst und den git status Befehl ausführst, erhältst du folgendes: $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: benchmarks.rb # The benchmarks.rb file appears under a section named Changed but not updated which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the git add command (it s a multipurpose command you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let s run git add now to stage the benchmarks.rb file, and then run git status again: Die Datei benchmarks.rb erscheint in der Sektion Changed but not updated - d.h., dass eine versionierte Datei im Arbeitsverzeichnis verändert worden ist, aber noch nicht für den Commit vorgemerkt wurde. Um sie zu vorzumerken, führst du den Befehl git add aus. (git add wird zu verschiedenen Zwecken eingesetzt. Man verwendet ihn, um neue Dateien zur Versionskontrolle hinzuzufügen, Dateien für einen Commit zu markieren und verschiedene andere Dinge - beispielsweise, einen Konflikt aus einem Merge als aufgelöst zu kennzeichnen.) $ git add benchmarks.rb $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # modified: benchmarks.rb # Both files are staged and will go into your next commit. At this point, suppose you remember 27

42 Chapter 3 Git Grundlagen Scott Chacon Pro Git one little change that you want to make in benchmarks.rb before you commit it. You open it again and make that change, and you re ready to commit. However, let s run git status one more time: Beide Dateien sind nun für den nächsten Commit vorgemerkt. Nehmen wir an, du willst jetzt aber noch eine weitere Änderung an der Datei benchmarks.rb vornehmen, bevor du den Commit tatsächlich anlegst. Du öffnest die Datei und änderst sie. Jetzt könntest du den Commit anlegen. Aber zuvor führen wir noch mal git status aus: $ vim benchmarks.rb $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # modified: benchmarks.rb # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: benchmarks.rb # What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the git add command. If you commit now, the version of benchmarks.rb as it was when you last ran the git add command is how it will go into the commit, not the version of the file as it looks in your working directory when you run git commit. If you modify a file after you run git add, you have to run git add again to stage the latest version of the file: Huch, was ist das? Jetzt wird benchmarks.rb sowohl als für den Commit vorgemerkt und als geändert aufgelistet. Die Erklärung dafür ist, dass Git eine Datei in exakt dem Zustand für den Commit vormerkt, in dem sie sich befindet, wenn du den Befehl git add ausführst. Wenn du den Commit jetzt anlegst, wird die Version der Datei benchmarks.rb diejenigen Inhalte haben, die sie hatte, als du git add zuletzt ausgeführt hast - nicht diejenigen, die sie in dem Moment hat, wenn du den Commit anlegst. Wenn du stattdessen die gegenwärtige Version im Commit haben willst, kannst du einfach erneut git add ausführen: $ git add benchmarks.rb $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # modified: benchmarks.rb # 28

43 Scott Chacon Pro Git Section 3.4 Änderungen am Repository nachverfolgen Ignoring Files Dateien ignorieren Often, you ll have a class of files that you don t want Git to automatically add or even show you as being untracked. These are generally automatically generated files such as log files or files produced by your build system. In such cases, you can create a file listing patterns to match them named.gitignore. Here is an example.gitignore file: Du wirst in der Regel eine Reihe von Dateien in deinem Projektverzeichnis haben, die du nicht versionieren oder im Repository haben willst, wie z.b. automatisch generierte Dateien wie Logdateien oder Dateien, die dein Build-System erzeugt. In solchen Fällen kannst du in einer Datei alle Dateien oder Dateimuster angeben, die du ignorieren willst. $ cat.gitignore *.[oa] *~ The first line tells Git to ignore any files ending in.o or.a object and archive files that may be the product of building your code. The second line tells Git to ignore all files that end with a tilde (~), which is used by many text editors such as Emacs to mark temporary files. You may also include a log, tmp, or pid directory; automatically generated documentation; and so on. Setting up a.gitignore file before you get going is generally a good idea so you don t accidentally commit files that you really don t want in your Git repository. Die erste Zeile weist Git an, alle Dateien zu ignorieren, die mit einem.o oder.a enden (also Objekt- und Archiv-Dateien, die von deinem Build-System erzeugt werden). Die zweite Zeile bewirkt, dass alle Dateien ignoriert werden, die mit einer Tilde (~) enden. Viele Texteditoren speichern ihre temporären Dateien auf diese Weise, wie bespielsweise Emacs. Du kannst außerdem Verzeichnisse wie log, tmp oder pid hinzufügen, automatisch erzeugte Dokumentation, und so weiter. Es ist normalerweise empfehlenswert, eine.gitignore Datei anzulegen, bevor man mit der eigentlichen Arbeit anfängt, damit man nicht versehentlich Dateien ins Repository hinzufügt, die man dort nicht wirklich haben will. The rules for the patterns you can put in the.gitignore file are as follows: Die Regeln für Einträge in der.gitignore Datei sind: Blank lines or lines starting with # are ignored. Standard glob patterns work. You can end patterns with a forward slash (/) to specify a directory. You can negate a pattern by starting it with an exclamation point (!). Leere Zeilen oder Zeilen, die mit # beginnen, werden ignoriert. Standard glob Muster funktionieren (siehe den nächsten Absatz). Du kannst ein Muster mit einem Schrägstrich (/) beenden, um ein Verzeichnis zu bezeichnen. Du kannst ein Muster negieren, indem du ein Ausrufezeichen (!) voranstellst. 29

44 Chapter 3 Git Grundlagen Scott Chacon Pro Git Glob patterns are like simplified regular expressions that shells use. An asterisk (*) matches zero or more characters; [abc] matches any character inside the brackets (in this case a, b, or c); a question mark (?) matches a single character; and brackets enclosing characters seperated by a hyphen([0-9]) matches any character between them (in this case 0 through 9). Glob Muster sind vereinfachte Reguläre Ausdrücke, die von der Shell verwendet werden. Ein Stern (*) bezeichnet kein oder mehrere Zeichen ; [abc] bezeichnet eines der in den eckigen Klammern angegebenen Zeichen (in diesem Fall also a, b oder c); ein Fragezeichen (?) bezeichnet ein beliebiges, einzelnes Zeichen; und eckige Klammern mit Zeichen, die von einem Bindestrich getrennt werden ([0-9]) bezeichnen ein Zeichen aus der jeweiligen Menge von Zeichen (in diesem Fall also aus der Menge der Zeichen von 0 bis 9). Here is another example.gitignore file: Hier ist noch ein Beispiel für eine.gitignore Datei: # a comment this is ignored *.a # no.a files!lib.a # but do track lib.a, even though you're ignoring.a files above /TODO # only ignore the root TODO file, not subdir/todo build/ # ignore all files in the build/ directory doc/*.txt # ignore doc/notes.txt, but not doc/server/arch.txt # ein Kommentar - er wird ignoriert *.a # ignoriert alle Dateien, die mit.a enden!lib.a # nicht aber lib.a Dateien (obwohl obige Zeile *.a ignoriert) /TODO # ignoriert eine TODO Datei nur im Wurzelverzeichnis, nicht aber # in Unterverzeichnissen build/ # ignoriert alle Dateien im build/ Verzeichnis doc/*.txt # ignoriert doc/notes.txt, aber nicht doc/server/arch.txt Viewing Your Staged and Unstaged Changes Die Änderungen in der Staging Area durchsehen If the git status command is too vague for you you want to know exactly what you changed, not just which files were changed you can use the git diff command. We ll cover git diff in more detail later; but you ll probably use it most often to answer these two questions: What have you changed but not yet staged? And what have you staged that you are about to commit? Although git status answers those questions very generally, git diff shows you the exact lines added and removed the patch, as it were. Wenn dir die Ausgabe des Befehl git status nicht aussagekräftig genug ist, weil du exakt wissen willst, was sich geändert hat - und nicht lediglich, welche Dateien überhaupt geändert wurden - kannst du den git diff Befehl verwenden. Wir werden git diff später noch mal im Detail besprechen, aber du wirst diesen Befehl in der Regel verwenden wollen, um eine der folgenden, zwei Fragen zu beantworten: Was hast du geändert, aber noch nicht für einen Commit vorgemerkt? Und was hast du für einen Commit bereits vorgemerkt? Während git status diese Fragen nur mit Dateinamen beantwortet, zeigt dir git diff exakt an, welche Zeilen hinzugefügt, geändert und entfernt wurden. (xxx the patch, as it were??? xxx) Let s say you edit and stage the README file again and then edit the benchmarks.rb file without 30

45 Scott Chacon Pro Git Section 3.4 Änderungen am Repository nachverfolgen staging it. If you run your status command, you once again see something like this: Nehmen wir an, du hast die Datei README geändert und für einen Commit in der Staging Area vorgemerkt. Dann änderst du außerdem die Datei benchmarks.rb, fügst sie aber noch nicht zur Staging Area hinzu. Wenn du den git status Befehl ausführst, zeigt er dir in etwa Folgendes an: $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # # modified: benchmarks.rb # To see what you ve changed but not yet staged, type git diff with no other arguments: Um zu sehen, welche Änderungen du bisher noch nicht für den Commit vorgemerkt hast, führe git diff ohne irgendwelche weiteren Argumente aus: $ git diff diff --git a/benchmarks.rb b/benchmarks.rb index 3cb747f..da a/benchmarks.rb +++ b/benchmarks.rb -36,6 +36,10 def end + run_code(x, 'commits 1') do + git.commits.size + end + run_code(x, 'commits 2') do log = git.commits('master', 15) log.size That command compares what is in your working directory with what is in your staging area. The result tells you the changes you ve made that you haven t yet staged. Dieser Befehl vergleicht die Inhalte deines Arbeitsverzeichnisses mit den Inhalten deiner Staging Area. Das Ergebnis zeigt dir die Änderungen, die du an Dateien im Arbeitsverzeichnis vorgenommen, aber noch nicht für den nächsten Commit vorgemerkt hast. If you want to see what you ve staged that will go into your next commit, you can use git diff -cached. (In Git versions and later, you can also use git diff -staged, which may be easier to remember.) This command compares your staged changes to your last commit: Wenn du sehen willst, welche Änderungen in der Staging Area und somit für den nächsten Commit vorgesehen sind, kannst du git diff --cached verwenden. (Ab der Version Git kannst 31

46 Chapter 3 Git Grundlagen Scott Chacon Pro Git du außerdem git diff --staged verwenden, was vielleicht leichter zu merken ist.) Dieser Befehl vergleicht die Inhalte der Staging Area mit dem letzten Commit: $ git diff --cached diff --git a/readme b/readme new file mode index a1 --- /dev/null +++ b/readme2 -0,0 +1,5 +grit + by Tom Preston-Werner, Chris Wanstrath Grit is a Ruby library for extracting information from a Git repository It s important to note that git diff by itself doesn t show all changes made since your last commit only changes that are still unstaged. This can be confusing, because if you ve staged all of your changes, git diff will give you no output. Es ist wichtig, im Kopf zu behalten, dass git diff selbst nicht alle Änderungen seit dem letzten Commit anzeigt - es zeigt lediglich diejenigen Änderungen an, die noch nicht in der Staging Area sind. Das kann verwirrend sein: wenn du all deine Änderungen bereits für einen Commit vorgemerkt hast, zeigt git diff überhaupt nichts an. For another example, if you stage the benchmarks.rb file and then edit it, you can use git diff to see the changes in the file that are staged and the changes that are unstaged: Ein anderes Beispiel. Wenn du Änderungen an der Datei benchmarks.rb bereits zur Staging Area hinzugefügt hast und sie dann anschließend noch mal änderst, kannst du git diff verwenden, um diese letzten Änderungen anzuzeigen, die noch nicht in der Staging Area sind: $ git add benchmarks.rb $ echo '# test line' >> benchmarks.rb $ git status # On branch master # # Changes to be committed: # # modified: benchmarks.rb # # Changed but not updated: # # modified: benchmarks.rb # Now you can use git diff to see what is still unstaged Jetzt kannst du git diff verwenden, um zu sehen, was noch nicht für den nächsten Commit vorgesehen ist: 32

47 Scott Chacon Pro Git Section 3.4 Änderungen am Repository nachverfolgen $ git diff diff --git a/benchmarks.rb b/benchmarks.rb index e445e28..86b2f7c a/benchmarks.rb +++ b/benchmarks.rb -127,3 +127,4 end main() ##pp Grit::GitRuby.cache_client.stats +# test line and git diff --cached to see what you ve staged so far: $ git diff --cached diff --git a/benchmarks.rb b/benchmarks.rb index 3cb747f..e445e a/benchmarks.rb +++ b/benchmarks.rb -36,6 +36,10 def end + run_code(x, 'commits 1') do + git.commits.size + end + run_code(x, 'commits 2') do log = git.commits('master', 15) log.size Committing Your Changes Einen Commit anlegen Now that your staging area is set up the way you want it, you can commit your changes. Remember that anything that is still unstaged any files you have created or modified that you haven t run git add on since you edited them won t go into this commit. They will stay as modified files on your disk. In this case, the last time you ran git status, you saw that everything was staged, so you re ready to commit your changes. The simplest way to commit is to type git commit: Nachdem du jetzt alle Änderungen, die du im nächsten Commit haben willst, in deiner Staging Area gesammelt hast, kannst du den Commit anlegen. Denke daran, dass Änderungen, die nicht in der Staging Area sind (also alle Änderungen, die du vorgenommen hast, seit du zuletzt git add ausgeführt hast), auch nicht in den Commit aufgenommen werden: sie werden ganz einfach weiterhin als geänderte Dateien im Arbeitsverzeichnis verbleiben. In unserem Beispiel haben wir gesehen, dass alle Änderungen vorgemerkt waren, als wir zuletzt git status ausgeführt haben, also können wir den Commit jetzt anlegen. Das geht am einfachsten mit dem Befehl: $ git commit Doing so launches your editor of choice. (This is set by your shell s $EDITOR environment 33

48 Chapter 3 Git Grundlagen Scott Chacon Pro Git variable usually vim or emacs, although you can configure it with whatever you want using the git config --global core.editor command as you saw in Chapter 1). Wenn du diesen Befehl ausführst, wird Git deinen Texteditor starten. (D.h. denjenigen Texteditor, der durch die $EDITOR Variable deiner Shell angegeben wird - normalerweise ist das vim oder emacs, aber du kannst jeden Editor deiner Wahl angeben. Wie in Kapitel 1 besprochen, kannst du dazu git config --global core.editor verwenden.) The editor displays the following text (this example is a Vim screen): Der Editor zeigt in etwa folgendes an (dies ist ein Vim Bespiel): # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # new file: README # modified: benchmarks.rb ~ ~ ~ ".git/commit_editmsg" 10L, 283C You can see that the default commit message contains the latest output of the git status command commented out and one empty line on top. You can remove these comments and type your commit message, or you can leave them there to help you remember what you re committing. (For an even more explicit reminder of what you ve modified, you can pass the -v option to git commit. Doing so also puts the diff of your change in the editor so you can see exactly what you did.) When you exit the editor, Git creates your commit with that commit message (with the comments and diff stripped out). Du siehst, dass die vorausgefüllte Commit Meldung die Ausgabe des letzten git status Befehls als einen Kommentar und darüber eine leere Zeile. Du kannst den Kommentar entfernen und deine eigene Meldung einfügen. Oder du kannst sie stehen lassen, damit du siehst, was im Commit enthalten sein wird. (Um die Änderungen noch detaillierter sehen zu können, kannst du den Befehl git commit mit der Option -v verwenden. Das fügt zusätzlich das Diff deiner Änderungen im Editor ein, so dass du exakt sehen kannst, was sich im Commit befindet.) Wenn du den Texteditor beendest, erzeugt Git den Commit mit der gegebenen Meldung (d.h., ohne den Kommentar und das Diff). Alternatively, you can type your commit message inline with the commit command by specifying it after a -m flag, like this: Alternativ kannst du die Commit Meldung direkt mit dem Befehl git commit angeben, indem du die Option -m wie folgt verwendest: $ git commit -m "Story 182: Fix benchmarks for speed" [master]: created 463dc4f: "Fix benchmarks for speed" 2 files changed, 3 insertions(+), 0 deletions(-) create mode README 34

49 Scott Chacon Pro Git Section 3.4 Änderungen am Repository nachverfolgen Now you ve created your first commit! You can see that the commit has given you some output about itself: which branch you committed to (master), what SHA-1 checksum the commit has (463dc4f), how many files were changed, and statistics about lines added and removed in the commit. Du hast jetzt deinen ersten Commit angelegt! Git zeigt dir als Rückmeldung einige Details über den neu angelegten Commit an: in welchem Branch er sich befindet (master), welche SHA-1 Checksumme er hat (463dc4f), wie viele Dateien geändert wurden und eine Zusammenfassung über die insgesamt neu hinzugefügten und entfernten Zeilen in diesem Commit. Remember that the commit records the snapshot you set up in your staging area. Anything you didn t stage is still sitting there modified; you can do another commit to add it to your history. Every time you perform a commit, you re recording a snapshot of your project that you can revert to or compare to later. Denke daran, dass jeder neue Commit denjenigen Snapshot aufzeichnet, den du in der Staging Area vorkonfiguriert hattest. Änderungen, die nicht in der Staging Area waren, werden weiterhin als modifizierte Dateien im Arbeitsverzeichnis vorliegen. Jedes Mal wenn du einen Commit anlegst, zeichnest du einen Snapshot Deines Projektes auf, zu dem du zurückkehren oder mit dem du spätere Änderungen vergleichen kannst Skipping the Staging Area Die Staging Area überspringen Although it can be amazingly useful for crafting commits exactly how you want them, the staging area is sometimes a bit more complex than you need in your workflow. If you want to skip the staging area, Git provides a simple shortcut. Providing the -a option to the git commit command makes Git automatically stage every file that is already tracked before doing the commit, letting you skip the git add part: Obwohl die Staging Area unglaublich nützlich ist, um genau diejenigen Commits anzulegen, die du in deiner Projekt Historie haben willst, ist sie manchmal auch ein bißchen umständlich. Git stellt dir deshalb eine Abkürzung zur Verfügung, mit der du die Staging Area überspringen kannst. Wenn du den Befehl git commit mit der Option -a ausführst, übernimmt Git automatisch alle Änderungen an dejenigen Dateien, die sich bereits unter Versionskontrolle befinden, in den Commit - so dass du auf diese Weise den Schritt git add weglassen kannst: $ git status # On branch master # # Changed but not updated: # # modified: benchmarks.rb # $ git commit -a -m 'added new benchmarks' [master 83e38c7] added new benchmarks 1 files changed, 5 insertions(+), 0 deletions(-) commit. Notice how you don t have to run git add on the benchmarks.rb file in this case before you 35

50 Chapter 3 Git Grundlagen Scott Chacon Pro Git Beachte, dass du in diesem Fall git add zuvor noch nicht ausgeführt hast, die Änderungen an benchmarks.rb aber dennoch in den Commit übernommen werden Removing Files Dateien entfernen To remove a file from Git, you have to remove it from your tracked files (more accurately, remove it from your staging area) and then commit. The git rm command does that and also removes the file from your working directory so you don t see it as an untracked file next time around. Um eine Datei aus der Git Versionskontrolle nehmen (genauer, aus der Staging Area) und dann einen Commit anlegen. Der Befehl git rm tut genau das - und löscht die Datei außerdem aus dem Arbeitsverzeichnis, so dass sie dort nicht unbeabsichtigt (als eine nun unversionierte Datei) liegen bleibt. If you simply remove the file from your working directory, it shows up under the Changed but not updated (that is, unstaged) area of your git status output: Wenn du einfach nur eine Datei aus dem Arbeitsverzeichnis löschst, wird sie in der Sektion Changed but not updated angezeigt, wenn du git status ausführst: $ rm grit.gemspec $ git status # On branch master # # Changed but not updated: # (use "git add/rm <file>..." to update what will be committed) # # deleted: grit.gemspec # Then, if you run git rm, it stages the file s removal: Wenn du jetzt git rm ausführst, wird diese Änderung für den nächsten Commit in der Staging Area vorgemerkt: $ git rm grit.gemspec rm 'grit.gemspec' $ git status # On branch master # # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # deleted: grit.gemspec # The next time you commit, the file will be gone and no longer tracked. If you modified the file and added it to the index already, you must force the removal with the -f option. This is a safety feature to prevent accidental removal of data that hasn t yet been recorded in a snapshot and that can t be recovered from Git. 36

51 Scott Chacon Pro Git Section 3.4 Änderungen am Repository nachverfolgen Wenn du als nächstes einen Commit anlegst, wird die Datei nicht mehr im Arbeitsverzeichnis liegen und sich nicht länger unter Versionskontrolle befinden. Wenn du die Datei zuvor geändert und diese Änderung bereits zur Staging Area hinzugefügt hattest, mußt du die Option -f verwenden, um zu erzwingen, dass sie gelöscht wird. Dies ist eine Sicherheitsmaßnahme, um zu vermeiden, dass du versehentlich Daten löschst, die sich bisher noch nicht als Commit Snapshot in der Historie deines Projektes befinden - und deshalb auch nicht wiederhergestellt werden können. Another useful thing you may want to do is to keep the file in your working tree but remove it from your staging area. In other words, you may want to keep the file on your hard drive but not have Git track it anymore. This is particularly useful if you forgot to add something to your.gitignore file and accidentally added it, like a large log file or a bunch of.a compiled files. To do this, use the --cached option: Ein anderer Anwendungsfall für git rm ist, dass du eine Datei in deinem Arbeitsverzeichnis behalten, aber aus der Staging Area nehmen willst. In anderen Worten, du willst die Datei nicht löschen, sondern aus der Versionskontrolle nehmen. Das könnte zum Beispiel der Fall sein, wenn du vergessen hattest, eine Datei in.gitignore anzugeben und sie versehentlich zur Versionskontrolle hinzugefügt hast, beispielsweise eine große Logdatei oder eine Reihe kompilierter.a Dateien. Hierzu kannst du dann die --cached Option verwenden: $ git rm --cached readme.txt You can pass files, directories, and file-glob patterns to the git rm command. That means you can do things such as Der git rm Befehl akzeptiert Dateien, Verzeichnisse und glob Dateimuster. D.h., du kannst z.b. folgendes tun: $ git rm log/\*.log Note the backslash (\) in front of the *. This is necessary because Git does its own filename expansion in addition to your shell s filename expansion. This command removes all files that have the.log extension in the log/ directory. Or, you can do something like this: Beachte den Backslash (\) vor dem Stern (*). Er ist nötig, weil Git Dateinamen zusätzlich zur Dateinamen-Expansion deiner Shell selbst vervollständigt. D.h., dieser Befehl entfernt alle Dateien, die die Erweiterung.log haben und sich im /log Verzeichnis befinden. Ein anderes Beispiel ist: $ git rm \*~ This command removes all files that end with ~. Dieser Befehl entfernt alle Dateien, die mit einer Tilde (~) aufhören. 37

52 Chapter 3 Git Grundlagen Scott Chacon Pro Git Moving Files Dateien verschieben Unlike many other VCS systems, Git doesn t explicitly track file movement. If you rename a file in Git, no metadata is stored in Git that tells it you renamed the file. However, Git is pretty smart about figuring that out after the fact we ll deal with detecting file movement a bit later. Anders als andere VCS Systeme verfolgt Git nicht explizit, ob Dateien verschoben werden. Wenn du eine Datei umbenennst, werden darüber keine Metadaten in der Historie gespeichert. Stattdessen ist Git schlau genug, solche Dinge im Nachhinein herauszufinden. Wir werden uns damit später noch befassen. Thus it s a bit confusing that Git has a mv command. If you want to rename a file in Git, you can run something like Es ist allerdings ein bißchen verwirrend, dass Git trotzdem einen git mv Befehl mit bringt. Wenn du eine Datei umbenennen willst, kannst du folgendes tun: $ git mv file_from file_to and it works fine. In fact, if you run something like this and look at the status, you ll see that Git considers it a renamed file: Das funktioniert. Wenn du diesen Befehl ausführst und danach den git status anzeigst, zeigt Git an, dass die Datei umbenannt wurde: $ git mv README.txt README $ git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # renamed: README.txt -> README # However, this is equivalent to running something like this: Allerdings kannst du genau so gut etwas wie das hier tun: $ mv README.txt README $ git rm README.txt $ git add README Git figures out that it s a rename implicitly, so it doesn t matter if you rename a file that way or with the mv command. The only real difference is that mv is one command instead of three it s a convenience function. More important, you can use any tool you like to rename a file, and address the add/rm later, before you commit. 38

53 Scott Chacon Pro Git Section 3.5 Viewing the Commit History Git ist clever genug, selbst herauszufinden, dass du die Datei umbenannt hast. Du brauchst dies also nicht explizit mit dem git mv Befehl zu tun. Der einzige Unterschied ist, dass du mit git mv nur einen Befehl, nicht drei, ausführen mußt - das ist natürlich etwas bequemer. Darüberhinaus kannst du aber Dateien auf jede beliebige Art und Weise extern umbenennen und dann später git add bzw. git rm verwenden, wenn du einen Commit zusammenstellst. 3.5 Viewing the Commit History 3.6 Die Commit Historie anzeigen After you have created several commits, or if you have cloned a repository with an existing commit history, you ll probably want to look back to see what has happened. The most basic and powerful tool to do this is the git log command. Nachdem du einige Commits angelegt oder ein bestehendes Repository geklont hast, willst du vielleicht wissen, welche Änderungen zuletzt vorgenommen wurden. Der grundlegendste Befehl, mit dem du das tun kannst, ist git log. These examples use a very simple project called simplegit that I often use for demonstrations. To get the project, run Die folgende Beispielen beziehen sich auf ein sehr simples Repository mit dem Namen simplegit, das ich oft für Demonstationszwecke verwende: git clone git:// When you run git log in this project, you should get output that looks something like this: Wenn du in diesem Projekt git log ausführst, solltest du eine Ausgabe wie die folgende sehen: $ git log commit ca82a6dff817ec66f a Author: Scott Chacon Date: Mon Mar 17 21:52: changed the verison number commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon Date: Sat Mar 15 16:40: removed unnecessary test code commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon Date: Sat Mar 15 10:31: first commit By default, with no arguments, git log lists the commits made in that repository in reverse chronological order. That is, the most recent commits show up first. As you can see, this command 39

54 Chapter 3 Git Grundlagen Scott Chacon Pro Git lists each commit with its SHA-1 checksum, the author s name and , the date written, and the commit message. Der Befehl git log listet die Historie der Commits eines Projektes in umgekehrter chronologischer Reihenfolge auf, wenn man ihn ohne weitere Argumente ausführt, d.h. die letzten Commits stehen oben. Wie du sehen kannst wird jeder Commit mit seiner SHA-1 Checksumme, Namen und Adresse des Autors, dem Datum und der Commit Meldung aufgelistet. A huge number and variety of options to the git log command are available to show you exactly what you re looking for. Here, we ll show you some of the most-used options. Für den Befehl git log gibt es eine riesige Anzahl von Optionen, mit denen man sehr genau eingrenzen kann, wonach man in einer Historie sucht. Schauen wir uns also einige der am häufigsten gebrauchten Optionen an. One of the more helpful options is -p, which shows the diff introduced in each commit. You can also use -2, which limits the output to only the last two entries: Eine sehr nützliche Option ist -p. Sie zeigt das Diff der Änderungen an, die in einem Commit enthalten sind. Du kannst außerdem 2 angeben, wodurch nur die letzten beiden Einträge angezeigt werden: $ git log p -2 commit ca82a6dff817ec66f a Author: Scott Chacon Date: Mon Mar 17 21:52: changed the verison number diff --git a/rakefile b/rakefile index a874b73..8f a/rakefile +++ b/rakefile -5,7 +5,7 require 'rake/gempackagetask' spec = do s - s.version = "0.1.0" + s.version = "0.1.1" = "Scott Chacon" commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon Date: Sat Mar 15 16:40: removed unnecessary test code diff --git a/lib/simplegit.rb b/lib/simplegit.rb index a0a60ae..47c a/lib/simplegit.rb +++ b/lib/simplegit.rb -18,8 +18,3 class SimpleGit end end - -if $0 == FILE - git = - puts 40

55 Scott Chacon Pro Git Section 3.6 Die Commit Historie anzeigen -end \ No newline at end of file This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added. You can also use a series of summarizing options with git log. For example, if you want to see some abbreviated stats for each commit, you can use the --stat option: Diese Option zeigt also im Prinzip die gleiche Information wie zuvor, aber zusätzlich zu jedem Eintrag ein Diff. Das ist nützlich, um einen Code Review zu machen oder eben mal eine Reihe von Commits durch zu schauen, die ein Mitarbeiter angelegt hat. Außerdem gibt es verschiedene Optionen, die nützlich sind, um Dinge zusammen zu fassen. Beispielsweise kannst du eine kurze Statistik über die jeden Commit mit der Option --stat anzeigen lassen: $ git log --stat commit ca82a6dff817ec66f a Author: Scott Chacon Date: Mon Mar 17 21:52: changed the verison number Rakefile files changed, 1 insertions(+), 1 deletions(-) commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 Author: Scott Chacon Date: Sat Mar 15 16:40: removed unnecessary test code lib/simplegit.rb files changed, 0 insertions(+), 5 deletions(-) commit a11bef06a3f659402fe7563abf99ad00de2209e6 Author: Scott Chacon Date: Sat Mar 15 10:31: first commit README Rakefile lib/simplegit.rb files changed, 54 insertions(+), 0 deletions(-) As you can see, the --stat option prints below each commit entry a list of modified files, how many files were changed, and how many lines in those files were added and removed. It also puts a summary of the information at the end. Another really useful option is --pretty. This option changes the log output to formats other than the default. A few prebuilt options are available for you to use. The oneline option prints each commit on a single line, which is useful if you re looking at a lot of commits. In addition, the short, full, and fuller options show the output in roughly the same format but with less or more information, respectively: 41

56 Chapter 3 Git Grundlagen Scott Chacon Pro Git Die --stat Option zeigt unterhalb jedes Commits eine kurze Statistik über die jeweiligen Änderungen an: welche Dateien geändert wurden und wieviele Zeilen insgesamt hinzugefügt oder entfernt wurden. Eine weitere nützliche Option ist --pretty. Diese Option ändert das Format der Ausgabe und es gibt eine Anzahl mitgelieferter Formate. Das oneline Format listet jeden Commit in einer einzigen Zeile, was nützlich ist, wenn du eine große Anzahl von Commits durchsuchen willst. Die short, full und fuller Formate zeigen die Commits in ähnlicher Form an, aber mit jeweils mehr oder weniger Informationen. $ git log --pretty=oneline ca82a6dff817ec66f a changed the verison number 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7 removed unnecessary test code a11bef06a3f659402fe7563abf99ad00de2209e6 first commit The most interesting option is format, which allows you to specify your own log output format. This is especially useful when you re generating output for machine parsing because you specify the format explicitly, you know it won t change with updates to Git: Eines der interessantesten Formate ist format, das dir erlaubt, dein eigenes Format zu verwenden. Dies ist inbesondere nützlich, wenn du die Ausgabe in ein anderes Programm einlesen willst (da du das Format explizit angibst, kannst du sicher sein, dass es sich nicht ändert, wenn du Git auf eine neuere Version aktualisierst): $ git log --pretty=format:"%h - %an, %ar : %s" ca82a6d - Scott Chacon, 11 months ago : changed the verison number 085bb3b - Scott Chacon, 11 months ago : removed unnecessary test code a11bef0 - Scott Chacon, 11 months ago : first commit Table 2.1 lists some of the more useful options that format takes. Tabelle 2-1 zeigt einige nützliche Optionen, die von format akzeptiert werden: Option Description of Output %H Commit hash %h Abbreviated commit hash %T Tree hash %t Abbreviated tree hash %P Parent hashes %p Abbreviated parent hashes %an Author name %ae Author %ad Author date (format respects the date= option) %ar Author date, relative %cn Committer name %ce Committer %cd Committer date %cr Committer date, relative %s Subject Option Beschreibung 42

57 Scott Chacon Pro Git Section 3.6 Die Commit Historie anzeigen %H Commit Hash %h Abgekürzter Commit Hash %T Baum Hash %t Abgekürzter Baum Hash %P Eltern Hashs %p Abgekürzte Eltern Hashs %an Autor Name %ae Autor %ad Autor Date (format akzeptiert eine date= Option) %ar Autor Date, relativ %cn Committer Name %ce Committer %cd Committer Date %cr Committer Date, relativ %s Betreff You may be wondering what the difference is between author and committer. The author is the person who originally wrote the work, whereas the committer is the person who last applied the work. So, if you send in a patch to a project and one of the core members applies the patch, both of you get credit you as the author and the core member as the committer. We ll cover this distinction a bit more in Chapter 5. Du fragst dich vielleicht, was der Unterschied zwischen Autor und Committer ist. Der Autor ist diejenige Person, die eine Änderung ursprünglich vorgenommen hat. Der Committer dagegen ist diejenige Person, die den Commit angelegt hat. D.h., wenn du einen Patch an ein Projekt Team schickst und eines der Team Mitglieder den Patch akzeptiert und verwendet, wird beiden Anerkennung gezollt (xxx) - sowohl dir als Autor als auch dem Team Mitglied als Comitter. Wir werden auf diese Unterschiedung in Kapitel 5 noch einmal genauer eingehen. The oneline and format options are particularly useful with another log option called --graph. This option adds a nice little ASCII graph showing your branch and merge history, which we can see our copy of the Grit project repository: Die oneline und format Optionen können außerdem zusammen mit einer weiteren Option --graph verwendet werden. Diese Option fügt einen netten kleinen ASCII Graphen hinzu, der die Branch- und Merge-Historie des Projektes anzeigt. Das kannst du z.b. in deinem Klon des Grit Projekt Repositories sehen: $ git log --pretty=format:"%h %s" --graph * 2d3acf9 ignore errors from SIGCHLD on trap * 5e3ee11 Merge branch 'master' of git:// \ * 420eac9 Added a method for getting the current branch. * 30e367c timeout code and tests * 5a09431 add timeout protection to grit * e1193f8 support for heads with slashes in them / * d6016bc require time for xmlschema * 11d191e Merge branch 'defunkt' into local Those are only some simple output-formatting options to git log there are many more. 43

58 Chapter 3 Git Grundlagen Scott Chacon Pro Git Table 2.2 lists the options we ve covered so far and some other common formatting options that may be useful, along with how they change the output of the log command. Das sind nur einige eher simple Format Optionen für die Ausgabe von git log - es gibt sehr viel mehr davon. Tabelle 2-2 listet diejenigen Optionen auf, die wir bisher besprochen haben, und einige weitere, die besonders nützlich sind: Option Description -p Show the patch introduced with each commit. --stat Show statistics for files modified in each commit. --shortstat Display only the changed/insertions/deletions line from the -- stat command. --name-only Show the list of files modified after the commit information. --name-status Show the list of files affected with added/modified/ deleted information as well. --abbrev-commit Show only the first few characters of the SHA-1 checksum instead of all relative-date Display the date in a relative format (for example, 2 weeks ago ) instead of using the full d --graph Display an ASCII graph of the branch and merge history beside the log output. --pretty Show commits in an alternate format. Options include oneline, short, full, fuller, and format (where Option Beschreibung -p Zeigt den Patch, der einem Commit entspricht. --stat Zeigt Statistiken über die in einem Commit geänderten Dateien und eingefügten/ entfernten Zeilen. --shortstat Zeigt nur die Kurzstatistik über eingefügte/entfernte Zeilen aus der `-- stat` Option. --name-only Zeigt die Liste der geänderte Dateien nach der Commit Information. --name-status Zeigt die Liste der Dateien mit der hinzugefügt/geändert/ entfernt Statistik. --abbrev-commit Zeigt nur die ersten Zeichen einer SHA-1 Checksumme, nicht alle relative-date Zeigt das Datum in relativem Format (z.b. "2 weeks ago"), nicht als vollständiges Datumsforma --graph Zeigt einen ASCII Graphen der Branch- und Merge-Historie neben der Ausgabe. --pretty Zeigt Commits in einem alternativen Format. Gültige Optionen sind: oneline, short, full, fuller und Limiting Log Output In addition to output-formatting options, git log takes a number of useful limiting options that is, options that let you show only a subset of commits. You ve seen one such option already the -2 option, which show only the last two commits. In fact, you can do -<n>, where n is any integer to show the last n commits. In reality, you re unlikely to use that often, because Git by default pipes all output through a pager so you see only one page of log output at a time. Zusätzlich zu den Formatierungsoptionen für die Ausgabe akzeptiert git log eine Reihe nützlicher Optionen, um die Anzahl der ausgegebenen Commits zu einzuschränken. Eine solche Option ist dir bereits begegnet: die -2 Option, die bewirkt, dass nur die letzten beiden Commits angezeigt werden. D.h., du kannst -<n> verwenden, wobei n irgendeine ganze Zahl sein kann. Im Alltag wirst du diese Option vermutlich nicht sehr oft verwenden, weil Git die Ausgabe standardmäßig durch einen Pager leitet (xxx) und nur jeweils eine Seite anzeigt. However, the time-limiting options such as --since and --until are very useful. For example, this command gets the list of commits made in the last two weeks: Aber es gibt auch Optionen, die Ausgabe auf der Basis von Zeitangaben zu einzugrenzen und 44

59 Scott Chacon Pro Git Section 3.6 Die Commit Historie anzeigen sehr hilfreich sein können. Beispielsweise gibt der folgende Befehl eine Liste aller Commits aus, die in den letzten zwei Wochen angelegt wurden: $ git log --since=2.weeks This command works with lots of formats you can specify a specific date ( ) or a relative date such as 2 years 1 day 3 minutes ago. Das funktioniert mit einer Reihe von Formaten. Git akzeptiert sowohl ein vollständiges Datum ( ) oder ein relatives Datum wie 2 years 1 day 3 minutes ago. You can also filter the list to commits that match some search criteria. The --author option allows you to filter on a specific author, and the --grep option lets you search for keywords in the commit messages. (Note that if you want to specify both author and grep options, you have to add --all-match or the command will match commits with either.) Du kannst außerdem die Liste der Commits nach Suchkriterien filtern. Die --author Option erlaubt, nach einem bestimmten Autoren zu suchen, und die --grep Option nach Stichworten in den Commit Meldungen. (Wenn du sowohl nach dem Autor als auch nach Stichworten suchen willst, mußt du zusätzlich --all-match angeben - andernfalls zeigt der Befehl alle Commits, die das eine oder das andere Kriterium erfüllen.) The last really useful option to pass to git log as a filter is a path. If you specify a directory or file name, you can limit the log output to commits that introduced a change to those files. This is always the last option and is generally preceded by double dashes (--) to separate the paths from the options. Eine letzte sehr nützliche Option, die von git log akzeptiert wird, ist ein Pfad. Wenn du einen Verzeichnis- oder Dateinamen angibst, kannst du die Ausgabe auf Commits einschränken, die sich auf die jeweiligen Verzeichnisse oder Dateien beziehen. Der Pfad muß als letztes angegeben und mit einem doppelten Bindestrich (--) von den Optionen getrennt werden. In Table 2.3 we ll list these and a few other common options for your reference. Tabelle 2-3 zeigt diese und einige weitere, übliche Optionen: Option Description -(n) Show only the last n commits --since, --after Limit the commits to those made after the specified date. --until, --before Limit the commits to those made before the specified date. --author Only show commits in which the author entry matches the specified string. --committer Only show commits in which the committer entry matches the specified string. Option Beschreibung -(n) Begrenzt die Ausgabe auf die letzten n commits --since, --after Zeigt nur Commits, die nach dem angegebenen Datum angelegt wurden. --until, --before Zeigt nur Commits, die vor dem angegebenen Datum angelegt wurden. --author Zeigt nur Commits, die von dem angegebenen Autor vorgenommen wurden. --committer Zeigt nur Commits, die von dem angegebenen Committer angelegt wurden. For example, if you want to see which commits modifying test files in the Git source code history were committed by Junio Hamano and were not merges in the month of October 2008, you can run something like this: 45

60 Chapter 3 Git Grundlagen Scott Chacon Pro Git Wenn du bespielsweise sehen willst, welche Commits den Tests im Git Quelltext von Junio Hamano im Oktober 2008 angelegt wurden und keine Merges waren, kannst du folgendes tun: $ git log --pretty="%h:%s" --author=gitster --since=" " \ --before=" " --no-merges -- t/ 5610e3b - Fix testcase failure when extended attribute acd3b9e - Enhance hold_lock_file_for_{update,append}() f demonstrate breakage of detached checkout wi d1a43f2 - reset --hard/read-tree --reset -u: remove un 51a94af - Fix "checkout --track -b newbranch" on detac b0ad11e - pull: allow "git pull origin $something:$cur Of the nearly 20,000 commits in the Git source code history, this command shows the 6 that match those criteria. Aus etwa Commits in der Git Quellcode Historie filtert dieser Befehl gerade einmal 6 Commits heraus, die diesen Kriterien entsprechen Using a GUI to Visualize History Eine GUI verwenden um die Historie anzuzeigen If you like to use a more graphical tool to visualize your commit history, you may want to take a look at a Tcl/Tk program called gitk that is distributed with Git. Gitk is basically a visual git log tool, and it accepts nearly all the filtering options that git log does. If you type gitk on the command line in your project, you should see something like Figure 2.2. Wenn dir eine grafische Darstellung lieber ist, um die Commit Historie anzuzeigen, kannst du die das Tcl/Tk Programm gitk ausprobieren, das mit Git ausgeliefert wird. gitk ist im wesentlichen eine grafische Version von git log und akzeptiert fast alle Filteroptionen, die git log auch akzeptiert. Wenn du gitk in einem Projekt ausführst, siehst du etwas wie: Figure 3.2: The gitk history visualizer Bild 2-2. Die gitk Oberfläche You can see the commit history in the top half of the window along with a nice ancestry graph. The diff viewer in the bottom half of the window shows you the changes introduced at any commit you click. Die Commit Historie wird in der oberen Hälfte des Fensters dargestellt, zusammen mit einem Graphen, der die Branches und Merges zeigt. Wenn du einen Commit anklickst, zeigt die Diff Anzeige in der unteren Hälfte des Fensters die jeweiligen Änderungen in diesem Commit. 46

61 Scott Chacon Pro Git Section 3.7 Undoing Things 3.7 Undoing Things 3.8 Änderungen rückgängig machen At any stage, you may want to undo something. Here, we ll review a few basic tools for undoing changes that you ve made. Be careful, because you can t always undo some of these undos. This is one of the few areas in Git where you may lose some work if you do it wrong. Es kommt immer wieder mal vor, dass du Änderungen rückgängig machen willst. Im Folgenden gehen wir auf einige grundlegende Möglichkeiten dazu ein. Sei allerdings vorsichtig damit, denn du kannst nicht immer alles wieder herstellen, was du rückgängig gemacht hast. Dies ist eine der wenigen Situationen in Git, in denen man Daten verlieren kann, wenn man es falsch macht Changing Your Last Commit Den letzten Commit ändern One of the common undos takes place when you commit too early and possibly forget to add some files, or you mess up your commit message. If you want to try that commit again, you can run commit with the --amend option: Manchmal hat man einen Commit zu früh angelegt und möglicherweise vergessen, einige Dateien hinzuzufügen, oder eine falsche Commit Meldung verwendet. Wenn du den letzten Commit korrigieren willst, kannst du dazu git commit zusammen mit der --amend Option verwenden: $ git commit --amend This command takes your staging area and uses it for the commit. If you ve have made no changes since your last commit (for instance, you run this command it immediately after your previous commit), then your snapshot will look exactly the same and all you ll change is your commit message. Dieser Befehl verwendet deine Staging Area für den Commit. Wenn du seit dem letzten Commit keine Änderungen vorgenommen hast (z.b. wenn du den Befehl unmittelbar nach einem Commit ausführst), wird der Snapshot exakt genauso aussehen wie der vorherige - alles, was du dann änderst, ist die Commit message. The same commit-message editor fires up, but it already contains the message of your previous commit. You can edit the message the same as always, but it overwrites your previous commit. Der Texteditor startet wie üblich, aber diesmal enthält er bereits die Meldung aus dem vorherigen Commit. Du kannst diese Meldung wie üblich bearbeiten, speichern und die vorherige Meldung dadurch überschreiben. As an example, if you commit and then realize you forgot to stage the changes in a file you wanted to add to this commit, you can do something like this: Wenn du beispielsweise einen Commit angelegt hast und dann feststellst, dass du zuvor vergessen hast, die Änderungen in einer bestimmten Datei zur Staging Area hinzuzufügen, kannst du folgendes tun: $ git commit -m 'initial commit' 47

62 Chapter 3 Git Grundlagen Scott Chacon Pro Git $ git add forgotten_file $ git commit --amend All three of these commands end up with a single commit the second command replaces the results of the first. Diese drei Befehle legen einen einzigen neuen Commit an - der letzte Befehl ersetzt dabei das Ergebnis des ersten Befehls Unstaging a Staged File Änderungen aus der Staging Area nehmen The next two sections demonstrate how to wrangle your staging area and working directory changes. The nice part is that the command you use to determine the state of those two areas also reminds you how to undo changes to them. For example, let s say you ve changed two files and want to commit them as two separate changes, but you accidentally type git add * and stage them both. How can you unstage one of the two? The git status command reminds you: Die nächsten zwei Abschnitte gehen darauf ein, wie du Änderungen in der Staging Area und dem Arbeitsverzeichnis verwalten (xxx wrangle xxx) kannst. Praktischerweise liefert dir der Befehl git status, den du verwendest, um den Status dieser beiden Bereiche zu überprüfen, zugleich auch eine Erinnerungshilfe dafür, wie du Änderungen rückgängig machen kanst. Nehmen wir beispielsweise an, du hast zwei Dateien geändert und willst sie als zwei seperate Commits anlegen, du hast aber versehentlich git add * ausgeführt und damit beide zur Staging Area hinzugefügt. Wie kannst du jetzt eine der beiden Änderungen wieder aus der Staging Area nehmen? git status gibt dir einen Hinweis: $ git add. $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: README.txt # modified: benchmarks.rb # Right below the Changes to be committed text, it says use git reset HEAD <file>... to unstage. So, let s use that advice to unstage the benchmarks.rb file: Direkt unter der Überschrift Changes to be committed findest du den Hinweis git reset HEAD <file>... to unstage, d.h. aus der Staging Area zu entfernen. Verwenden wir also diesen Befehl, um die Änderungen an der Datei benchmarks.rb aus der Staging Area zu nehmen: $ git reset HEAD benchmarks.rb benchmarks.rb: locally modified $ git status 48

63 Scott Chacon Pro Git Section 3.8 Änderungen rückgängig machen # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: README.txt # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: benchmarks.rb # The command is a bit strange, but it works. The benchmarks.rb file is modified but once again unstaged. Der Befehl liest sich zunächst vielleicht etwas merkwürdig, aber wie du siehst, funktioniert er. Die Datei benchmarks.rb ist jetzt geändert, aber nicht in der Staging Area Unmodifying a Modified File Eine Änderung an einer Datei rückgängig machen What if you realize that you don t want to keep your changes to the benchmarks.rb file? How can you easily unmodify it revert it back to what it looked like when you last committed (or initially cloned, or however you got it into your working directory)? Luckily, git status tells you how to do that, too. In the last example output, the unstaged area looks like this: Was aber, wenn du die Änderungen an der Datei benchmarks.rb überhaupt nicht beibehalten willst? D.h., wenn du sie in den Zustand zurückversetzen willst, in dem sie sich befand, als du den letzten Commit angelegt hast (oder das Repository geklont hast). Das ist einfach, und glücklicherweise gibt der git status Befehl ebenfalls bereits einen Hinweis darauf. Die obige Ausgabe enthält den folgenden Text: # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: benchmarks.rb # It tells you pretty explicitly how to discard the changes you ve made (at least, the newer versions of Git, and later, do this if you have an older version, we highly recommend upgrading it to get some of these nicer usability features). Let s do what it says: Das sagt ziemlich klar, was wir zu tun haben, wenn wir die Änderungen an der Datei verwerfen wollen (genauer gesagt, Git tut dies seit der Version wenn du eine ältere Version hast, empfehlen wir dir, sie zu aktualisieren). Also, tun wir das: 49

64 Chapter 3 Git Grundlagen Scott Chacon Pro Git $ git checkout -- benchmarks.rb $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: README.txt # You can see that the changes have been reverted. You should also realize that this is a dangerous command: any changes you made to that file are gone you just copied another file over it. Don t ever use this command unless you absolutely know that you don t want the file. If you just need to get it out of the way, we ll go over stashing and branching in the next chapter; these are generally better ways to go. Die Änderung wurde also rückgängig gemacht: sie taucht nicht mehr in der Liste der geänderten Dateien auf. Sei dir bewußt, dass dieser Befehl potentiell gefährlich ist, insofern er Änderungen an einer Datei vollständig verwirft. Es ist also ratsam, ihn nur dann zu verwenden, wenn du dir absolut sicher bist, dass du die Änderungen nicht mehr brauchst. Für Situationen, in denen Du eine Änderung lediglich vorläufig aus dem Weg räumen willst, werden wir im nächsten Kapitel noch auf Stashing und Branching eingehen - die dazu besser geeignet sind. Remember, anything that is committed in Git can almost always be recovered. Even commits that were on branches that were deleted or commits that were overwritten with an --amend commit can be recovered (see Chapter 9 for data recovery). However, anything you lose that was never committed is likely never to be seen again. Beachte, dass was auch immer jemals in einem Commit in Git enthalten war, fast immer wieder hergestellt werden kann. Selbst Commits, die sich in gelöschten Branches befanden, oder Commits, die mit einem --amend Commit überschrieben wurden, können wieder hergestellt werden (siehe Kapitel 9 für Datenrettung). Allerdings wirst du Änderungen, die es nie in einen Commit geschafft haben, wahrscheinlich auch nie wieder bekommen können. (xxx Mantra: commit early and often xxx) 3.9 Working with Remotes 3.10 Mit externen Repositories arbeiten To be able to collaborate on any Git project, you need to know how to manage your remote repositories. Remote repositories are versions of your project that are hosted on the Internet or network somewhere. You can have several of them, each of which generally is either read-only or read/write for you. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work. Managing remote repositories includes knowing how to add remote repositories, remove remotes that are no longer valid, manage various remote branches and define them as being tracked or not, and more. In this section, we ll cover these remote-management skills. Um mit anderen via Git zusammenarbeiten zu können, mußt du wissen, wie du auf externe ( remote ) Repositories zugreifen kannst. Externe Repositories sind Versionen deines Projektes, die im Internet oder irgendwo in einem anderen Netzwerk gespeichert sind. Du kannst mehrere solcher 50

65 Scott Chacon Pro Git Section 3.10 Mit externen Repositories arbeiten Repositories haben und du kannst jedes davon entweder nur lesen oder lesen und schreiben. Mit anderen via Git zusammenzuarbeiten impliziert, solche Repositories zu verwalten und Daten aus ihnen herunter- oder heraufzuladen, um deine Arbeit für andere verfügbar zu machen. Um externe Repositories zu verwalten, muß man wissen, wie man sie anlegt und wieder entfernt, wenn sie nicht mehr verwendet werden, wie man externe Branches verwalten und nachverfolgen kann, und mehr. In diesem Kapitel werden wir auf diese Aufgaben eingehen Showing Your Remotes Externe Repositories anzeigen To see which remote servers you have configured, you can run the git remote command. It lists the shortnames of each remote handle you ve specified. If you ve cloned your repository, you should at least see origin that is the default name Git gives to the server you cloned from: Der git remote Befehl zeigt dir an, welche externen Server du für dein Projekt lokal konfiguriert hast, und listet die Kurzbezeichnungen für jedes externe Repository auf. Wenn du ein Repository geklont hast, solltest du mindestens origin sehen - welches der Standardname ist, den Git für denjenigen Server vergibt, von dem Du klonst: $ git clone git:// Initialized empty Git repository in /private/tmp/ticgit/.git/ remote: Counting objects: 595, done. remote: Compressing objects: 100% (269/269), done. remote: Total 595 (delta 255), reused 589 (delta 253) Receiving objects: 100% (595/595), KiB 1 KiB/s, done. Resolving deltas: 100% (255/255), done. $ cd ticgit $ git remote origin You can also specify -v, which shows you the URL that Git has stored for the shortname to be expanded to: Du kannst außerdem die Option -v verwenden, was für jeden Kurznamen auch die jeweilige URL anzeigt, die Git gespeichert hat: $ git remote -v origin git:// If you have more than one remote, the command lists them all. For example, my Grit repository looks something like this. Wenn du mehr als ein externes Repository konfiguriert hast, zeigt der Befehl alle an. Für mein eigenes Grit Repository sieht das beispielsweise wie folgt aus: $ cd grit $ git remote -v 51

66 Chapter 3 Git Grundlagen Scott Chacon Pro Git bakkdoor cho45 defunkt koke origin git:// git:// git:// git:// This means we can pull contributions from any of these users pretty easily. But notice that only the origin remote is an SSH URL, so it s the only one I can push to (we ll cover why this is in Chapter 4). D.h., mein lokales Repository kennt die Repositories von all diesen Leuten und ich kann ihre Beiträge zu meinem Projekt ganz einfach herunterladen und zum Projekt hinzufügen Adding Remote Repositories Externe Repositories hinzufügen I ve mentioned and given some demonstrations of adding remote repositories in previous sections, but here is how to do it explicitly. To add a new remote Git repository as a shortname you can reference easily, run git remote add [shortname] [url]: Ich habe in vorangegangenen Kapiteln schon Beispiele dafür gegeben, wie man ein externes Repository hinzufügen kann, aber ich will noch einmal explizit darauf eingehen. Um ein neues externes Repository mit einem Kurznamen hinzuzufügen, den du dir leicht merken kannst, führst du den Befehl git remote add [shortname] [url] aus: $ git remote origin $ git remote add pb git:// $ git remote -v origin git:// pb git:// Now you can use the string pb on the command line in lieu of the whole URL. For example, if you want to fetch all the information that Paul has but that you don t yet have in your repository, you can run git fetch pb: Jetzt kannst du den Namen pb anstelle der vollständingen URL in verschiedenen Befehlen verwenden. Wenn du bespielsweise alle Informationen, die in Paul s, aber noch nicht in deinem eigenen Repository verfügbar sind, herunterladen willst, kannst du den Befehl git fetch pb verwenden: $ git fetch pb remote: Counting objects: 58, done. remote: Compressing objects: 100% (41/41), done. remote: Total 44 (delta 24), reused 1 (delta 0) Unpacking objects: 100% (44/44), done. From git:// * [new branch] master -> pb/master * [new branch] ticgit -> pb/ticgit 52

67 Scott Chacon Pro Git Section 3.10 Mit externen Repositories arbeiten Paul s master branch is accessible locally as pb/master you can merge it into one of your branches, or you can check out a local branch at that point if you want to inspect it. Paul s master Branch ist jetzt lokal auf deinem Rechner als pb/master verfügbar - du kannst ihn mit einem deiner eigenen Branches zusammenführen oder auf einen lokalen Branch wechseln, um damit zu arbeiten Fetching and Pulling from Your Remotes Aus externen Repositories herunterladen und ziehen As you just saw, to get data from your remote projects, you can run Wie du gerade gesehen hast, kannst du Daten aus externen Repositories herunterladen, indem du den Befehl verwendest: $ git fetch [remote-name] The command goes out to that remote project and pulls down all the data from that remote project that you don t have yet. After you do this, you should have references to all the branches from that remote, which you can merge in or inspect at any time. (We ll go over what branches are and how to use them in much more detail in Chapter 3.) Dieser Befehl lädt alle Daten aus dem externen Repository herunter, die noch nicht auf deinem Rechner verfügbar sind. Danach kennt dein eigenes Repository Verweise auf alle Branches in dem externen Repository, die du jederzeit mit deinen eigenen Branches zusammenführen oder lesen kannst. (Wir werden in Kapitel 3 detaillierter darauf eingehen, was genau Branches sind.) If you cloned a repository, the command automatically adds that remote repository under the name origin. So, git fetch origin fetches any new work that has been pushed to that server since you cloned (or last fetched from) it. It s important to note that the fetch command pulls the data to your local repository it doesn t automatically merge it with any of your work or modify what you re currently working on. You have to merge it manually into your work when you re ready. Wenn du ein Repository geklont hast, legt der Befehl automatisch einen Verweis auf dieses Repository unter dem Namen origin an. D.h. git fetch origin lädt alle Neuigkeiten herunter, die in dem externen Repository von anderen hinzugefügt wurden, seit du es geklont hast (oder zuletzt git fetch ausgeführt hast). Es ist wichtig, zu verstehen, dass der git fetch Befehl Daten lediglich in dein lokale Repository lädt. Er führt sich mit deinen eigenen Commits in keiner Weise zusammen oder modifiziert, woran du gerade arbeitest. D.h. du mußt die heruntergeladenen Änderungen anschließend selbst manuell mit deinen eigenen zusammeführen, wenn du das willst. If you have a branch set up to track a remote branch (see the next section and Chapter 3 for more information), you can use the git pull command to automatically fetch and then merge a remote branch into your current branch. This may be an easier or more comfortable workflow for you; and by default, the git clone command automatically sets up your local master branch to track the remote master branch on the server you cloned from (assuming the remote has a master branch). Running git pull generally fetches data from the server you originally cloned from and automatically tries to merge it into the code you re currently working on. Wenn du allerdings einen Branch so aufgesetzt hast, dass er einem externen Branch folgt (also einen Tracking Branch, wir werden im nächsten Abschnitt und in Kapitel 3 noch genauer 53

68 Chapter 3 Git Grundlagen Scott Chacon Pro Git darauf eingehen), dann kannst du den Befehl git pull verwenden, um automatisch neue Daten herunterzuladen und den externen Branch gleichzeitig mit dem aktuellen, lokalen Branch zusammenzuführen. Das ist oft die bequemere Arbeitsweise. git clone setzt deinen lokalen master Branch deshalb standardmäßig so auf, dass er dem externen master Branch des geklonten Repositories folgt (sofern das externe Repository einen master Branch hat). Wenn du dann git pull ausführst, wird Git die neuen Commits aus dem externen Repository holen und versuchen, sie automatisch mit dem Code zusammenzuführen, an dem du gerade arbeitest Pushing to Your Remotes Änderungen in ein externes Repository hochladen When you have your project at a point that you want to share, you have to push it upstream. The command for this is simple: git push [remote-name] [branch-name]. If you want to push your master branch to your origin server (again, cloning generally sets up both of those names for you automatically), then you can run this to push your work back up to the server: Wenn du mit deinem Projekt an einen Punkt gekommen bist, an dem du es anderen zur Verfügung stellen willst, kannst du deine Änderungen in ein gemeinsam genutztes Repository hochladen ( pushen ). Der Befehl dafür ist einfach: git push [remote-name] [branch-name]. Wenn du deinen master Branch auf den origin Server hochladen willst (noch einmal, wenn du ein Repository klonst, setzt Git diesen Namen automatisch für dich), dann kannst du diesen Befehl verwenden: $ git push origin master This command works only if you cloned from a server to which you have write access and if nobody has pushed in the meantime. If you and someone else clone at the same time and they push upstream and then you push upstream, your push will rightly be rejected. You ll have to pull down their work first and incorporate it into yours before you ll be allowed to push. See Chapter 3 for more detailed information on how to push to remote servers. Das funktioniert nur dann, wenn du Schreibrechte für das jeweilige Repository hast und niemand anders in der Zwischenzeit irgendwelche Änderungen hochgeladen hat. Wenn zwei Leute ein Repository zur gleichen Zeit klonen, dann zuerst der eine seine Änderungen hochlädt und der zweite anschließend versucht, das gleiche zu tun, dann wird sein Versuch korrekterweise abgewiesen. In dieser Situation muß man neue Änderungen zunächst herunterladen und mit seinen eigenen zusammenführen, um sie dann erst hochzuladen. In Kapitel 3 gehen wir noch einmal ausführlicher darauf ein Inspecting a Remote Ein externes Repository inspizieren If you want to see more information about a particular remote, you can use the git remote show [remote-name] command. If you run this command with a particular shortname, such as origin, you get something like this: 54

69 Scott Chacon Pro Git Section 3.10 Mit externen Repositories arbeiten Wenn du etwas über ein bestimmtes, externes Repository wissen willst, kannst du den Befehl git remote show [remote-name] verwenden. Wenn du diesen Befehl mit dem entsprechenden Kurznamen, z.b. origin verwendest, erhältst du etwas wie: $ git remote show origin * remote origin URL: git:// Remote branch merged with 'git pull' while on branch master master Tracked remote branches master ticgit It lists the URL for the remote repository as well as the tracking branch information. The command helpfully tells you that if you re on the master branch and you run git pull, it will automatically merge in the master branch on the remote after it fetches all the remote references. It also lists all the remote references it has pulled down. Das zeigt dir die URL für das externe Repository, die Tracking Information (xxx) für Branches und welcher Branch aus dem externen Repository mit deinem eigenen Master zusammengeführt wird, wenn du git pull ausführst. That is a simple example you re likely to encounter. When you re using Git more heavily, however, you may see much more information from git remote show: Dies ist ein eher einfaches Beispiel, das dir früher oder später so ähnlich über den Weg laufen wird. Wenn du Git aber täglich verwendest, erhältst du mit git remote show sehr viel mehr Informationen: $ git remote show origin * remote origin URL: Remote branch merged with 'git pull' while on branch issues issues Remote branch merged with 'git pull' while on branch master master New remote branches (next fetch will store in remotes/origin) caching Stale tracking branches (use 'git remote prune') libwalker walker2 Tracked remote branches acl apiv2 dashboard2 issues master postgres Local branch pushed with 'git push' master:master This command shows which branch is automatically pushed when you run git push on cer- 55

70 Chapter 3 Git Grundlagen Scott Chacon Pro Git tain branches. It also shows you which remote branches on the server you don t yet have, which remote branches you have that have been removed from the server, and multiple branches that are automatically merged when you run git pull. Dieser Befehl zeigt, welcher Branch automatisch hochgeladen werden wird, wenn du git push auf bestimmten Branches ausführst. Er zeigt außerdem, welche Branches es im externen Repository gibt, die du selbst noch nicht hast, welche Branches dort gelöscht wurden, und Branches, die automatisch mit lokalen Branches zusammengeführt werden, wenn du git pull ausführst Removing and Renaming Remotes Verweise auf externe Repositories löschen und umbenennen If you want to rename a reference, in newer versions of Git you can run git remote rename to change a remote s shortname. For instance, if you want to rename pb to paul, you can do so with git remote rename: Wenn du eine Referenz auf ein externes Repository umbenennen willst, kannst du in neueren Git Versionen den Befehl git remote rename verwenden, um den Kurznamen zu ändern. Wenn du beispielsweise pb in paul umbenennen willst, lautet der Befehl: $ git remote rename pb paul $ git remote origin paul It s worth mentioning that this changes your remote branch names, too. What used to be referenced at pb/master is now at paul/master. Beachte dabei, dass dies deine Branch Namen für externe Branches ebenfalls ändert. Der Branch, der zuvor mit pb/master referenziert werden konnte, heißt jetzt paul/master. If you want to remove a reference for some reason you ve moved the server or are no longer using a particular mirror, or perhaps a contributor isn t contributing anymore you can use git remote rm: Wenn du eine Referenz aus irgendeinem Grund entfernen willst (z.b. weil du den Server umgezogen hast oder einen bestimmten Mirror nicht länger verwendest, oder weil jemand vielleicht nicht länger mitarbeitet), kannst du git remote rm verwenden: $ git remote rm paul $ git remote origin 3.11 Tagging 3.12 Tagging Like most VCSs, Git has the ability to tag specific points in history as being important. Generally, people use this functionality to mark release points (v1.0, and so on). In this section, you ll learn how 56

71 Scott Chacon Pro Git Section 3.12 Tagging to list the available tags, how to create new tags, and what the different types of tags are. Wie die meisten anderen VCS kann Git bestimmte Punkte in der Historie als besonders wichtig markieren, also taggen. Normalerweise verwendet man diese Funktionalität, um Release Versionen zu markieren (z.b. v1.0). In diesem Abschnitt gehen wir darauf ein, wie du die vorhandenen Tags anzuzeigen und neue Tags erstellen kannst, und worin die Unterschiede zwischen verschiedenen Typen von Tags bestehen Listing Your Tags Vorhandene Tags anzeigen Listing the available tags in Git is straightforward. Just type git tag: Um die in einem Repository vorhandenen Tags anzuzeigen, kannst den Befehl git tag ohne irgendwelche weiteren Optionen verwenden: $ git tag v0.1 v1.3 This command lists the tags in alphabetical order; the order in which they appear has no real importance. Dieser Befehl listet die Tags in alphabetischer Reihenfolge auf. You can also search for tags with a particular pattern. The Git source repo, for instance, contains more than 240 tags. If you re only interested in looking at the series, you can run this: Du kannst auch nach Tags mit einem bestimmten Muster suchen. Das Git Quellcode Repository enthält beispielsweise mehr als 240 Tags. Wenn du nur an denjenigen interessiert bist, die zur Serie gehören, kannst du folgendes tun: $ git tag -l 'v1.4.2.*' v v v v Creating Tags Neue Tags anlegen Git uses two main types of tags: lightweight and annotated. A lightweight tag is very much like a branch that doesn t change it s just a pointer to a specific commit. Annotated tags, however, are stored as full objects in the Git database. They re checksummed; contain the tagger name, , and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). It s generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don t want to keep the other information, lightweight tags are available too. 57

72 Chapter 3 Git Grundlagen Scott Chacon Pro Git Git kennt im wesentlichen zwei Typen von Tags: leichte und kommentierte (xxx) ( lightweight und annotated ) Tags. Ein leichter Tag ist ein Branch, der sich niemals ändert - es ist lediglich ein Zeiger auf einen bestimmten Commit. Kommentierte Tags dagegen werden als vollwertige Objekte in der Git Datenbank gespeichert. Sie haben eine Checksumme, beinhalten Namen und Adresse desjenigen, der den Tag angelegt hat, das jeweilige Datum sowie eine Meldung. Sie können überdies mit GNU Privacy Guard (GPG) signiert und verifiziert werden. Generell empfiehlt sich deshalb, kommentierte Tags anzulegen. Wenn man aber aus irgendeinem Grund einen temporären Tag anlegen will, für den all diese zusätzlichen Informationen nicht nötig sind, dann kann man auf leichte Tags zurückgreifen Annotated Tags Kommentierte Tags (xxx) Creating an annotated tag in Git is simple. The easiest way is to specify -a when you run the tag command: Einen kommentierten Tag legst du an, indem du dem git tag Befehl die Option -a übergibst: $ git tag -a v1.4 -m 'my version 1.4' $ git tag v0.1 v1.3 v1.4 The -m specifies a tagging message, which is stored with the tag. If you don t specify a message for an annotated tag, Git launches your editor so you can type it in. Die Option -m gibt dabei wiederum die Meldung an, die zum Tag hinzugefügt wird. Wenn du keine Meldung angibst, startet Git wie üblich deinen Editor, so dass du eine Meldung eingeben kannst. You can see the tag data along with the commit that was tagged by using the git show command: git show zeigt dir dann folgenden Tag Daten zusammen mit dem jeweiligen Commit, auf den der Tag verweist: $ git show v1.4 tag v1.4 Tagger: Scott Chacon Date: Mon Feb 9 14:45: my version 1.4 commit b64cf874c3557a0f3547bd83b3ff6 Merge: 4a447f7... a6b4c97... Author: Scott Chacon Date: Sun Feb 8 19:02: Merge branch 'experiment' That shows the tagger information, the date the commit was tagged, and the annotation message before showing the commit information. 58

73 Scott Chacon Pro Git Section 3.12 Tagging Die Ausgabe listet also zunächst die Informationen über denjenigen, der den Tag angelegt hat, sowie die Tag Meldung und dann die Commit Informationen selbst Signed Tags Signierte Tags You can also sign your tags with GPG, assuming you have a private key. All you have to do is use -s instead of -a: Wenn du einen privaten GPG Schlüssel hast, kannst du deine Tags zusätzlich mit GPG signieren. Dazu verwendest du einfach die Option -s anstelle von -a: $ git tag -s v1.5 -m 'my signed 1.5 tag' You need a passphrase to unlock the secret key for user: "Scott Chacon 1024-bit DSA key, ID F721C45A, created kennt: If you run git show on that tag, you can see your GPG signature attached to it: Wenn du jetzt git show auf diesen Tag anwendest, siehst du, dass der Tag deine GPG Signatur $ git show v1.5 tag v1.5 Tagger: Scott Chacon Date: Mon Feb 9 15:22: my signed 1.5 tag -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) ieyeabecaayfakmquriacgkqon3dxfchxfr5caceimn+zxlkggjqf0qyiqbwgysn Ki0An2JeAVUCAiJ7Ox6ZEtK+NvZAj82/ =WryJ -----END PGP SIGNATURE----- commit b64cf874c3557a0f3547bd83b3ff6 Merge: 4a447f7... a6b4c97... Author: Scott Chacon Date: Sun Feb 8 19:02: Merge branch 'experiment' A bit later, you ll learn how to verify signed tags. Darauf, wie du signierte Tags verifizieren kannst, werden wir gleich noch eingehen Lightweight Tags Leichte Tags (xxx) Another way to tag commits is with a lightweight tag. This is basically the commit checksum stored in a file no other information is kept. To create a lightweight tag, don t supply the -a, -s, 59

74 Chapter 3 Git Grundlagen Scott Chacon Pro Git or -m option: Leichte Tags sind die zweite Form von Tags, die Git kennt. Für einen leichten Tag wird im wesentlichen die jeweilige Commit Checksumme, und sonst keine andere Information, in einer Datei gespeichert. Um einen leichten Tag anzulegen, verwendest du einfach keine der drei Optionen -a, -s und -m: $ git tag v1.4-lw $ git tag v0.1 v1.3 v1.4 v1.4-lw v1.5 This time, if you run git show on the tag, you don t see the extra tag information. The command just shows the commit: Wenn du jetzt git show auf den Tag ausführst, siehst du keine der zusätzlichen Tag Informationen. Der Befehl zeigt einfach den jeweiligen Commit: $ git show v1.4-lw commit b64cf874c3557a0f3547bd83b3ff6 Merge: 4a447f7... a6b4c97... Author: Scott Chacon Date: Sun Feb 8 19:02: Merge branch 'experiment' Verifying Tags Tags verifizieren To verify a signed tag, you use git tag -v [tag-name]. This command uses GPG to verify the signature. You need the signer s public key in your keyring for this to work properly: Um einen signierten Tag zu verifizieren, kannst du git tag -v [tag-name] verwenden. Dieser Befehl verwendet GPG, um die Signatur mit Hilfe des öffentlichen Schlüssels des Signierenden zu verifizieren - weshalb du diesen Schlüssel in deinem Schlüsselbund haben mußt: $ git tag -v v object babd8ee7ea23e6a5c392bb739348b1eb61 type commit tag v tagger Junio C Hamano GIT Minor fixes since 1.4.2, including git-mv and git-http with alternates. gpg: Signature made Wed Sep 13 02:08: PDT using DSA key ID F3119B9A 60

75 Scott Chacon Pro Git Section 3.12 Tagging gpg: Good signature from "Junio C Hamano gpg: aka "[jpeg image of size 1513]" Primary key fingerprint: A E066 C9A7 4A7D C0C6 D9A4 F311 9B9A If you don t have the signer s public key, you get something like this instead: Wenn du den öffentlichen Schlüssel des Signierenden nicht in deinem Schlüsselbund hast, wirst du statt dessen eine Meldung sehen wie: gpg: Signature made Wed Sep 13 02:08: PDT using DSA key ID F3119B9A gpg: Can't check signature: public key not found error: could not verify the tag 'v ' Tagging Later Nachträglich taggen You can also tag commits after you ve moved past them. Suppose your commit history looks like this: Du kannst Commits jederzeit taggen, auch lange Zeit nachdem sie angelegt wurden. Nehmen wir an, deine Commit Historie sieht wie folgt aus: $ git log --pretty=oneline b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment' a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 0d52aaab da7686c15f77a3d64d one more thing 6d52a271eda dd79daabbc4d9b6008e Merge branch 'experiment' 0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function 4682c bdd616e23b64b0857d832627b added a todo file 166ae0c4d3f420721acbb115cc33848dfcc2121a started write support 9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile 964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo 8a5cbc430f1a9c3d00faaeffd a updated readme Now, suppose you forgot to tag the project at v1.2, which was at the updated rakefile commit. You can add it after the fact. To tag that commit, you specify the commit checksum (or part of it) at the end of the command: Nehmen wir außerdem an, dass du vergessen hast, Version v1.2 des Projektes zu taggen, und dass dies der Commit updated rakefile gewesen ist. Du kannst diesen jetzt im Nachhinein taggen, indem du die Checksumme des Commits (oder einen Teil davon) am Ende des Befehls angibst: $ git tag -a v1.2 9fceb02 You can see that you ve tagged the commit: Du siehst jetzt, dass du einen Tag für den Commit angelegt hast: 61

76 Chapter 3 Git Grundlagen Scott Chacon Pro Git $ git tag v0.1 v1.2 v1.3 v1.4 v1.4-lw v1.5 $ git show v1.2 tag v1.2 Tagger: Scott Chacon Date: Mon Feb 9 15:32: version 1.2 commit 9fceb02d0ae598e95dc970b74767f19372d61af8 Author: Magnus Chacon Date: Sun Apr 27 20:43: updated rakefile Sharing Tags Tags hochladen (xxx) By default, the git push command doesn t transfer tags to remote servers. You will have to explicitly push tags to a shared server after you have created them. This process is just like sharing remote branches you can run git push origin [tagname]. Der git push Befehl lädt Tags nicht von sich aus auf externe Server. Stattdessen muß Du Tags explizit auf einen externen Server hochladen, nachdem du sie angelegt hast. Der Vorgang ist derselbe wie mit Branches: du kannst den Befehl git push origin [tagname] verwenden. $ git push origin v1.5 Counting objects: 50, done. Compressing objects: 100% (38/38), done. Writing objects: 100% (44/44), 4.56 KiB, done. Total 44 (delta 18), reused 8 (delta 1) To * [new tag] v1.5 -> v1.5 If you have a lot of tags that you want to push up at once, you can also use the --tags option to the git push command. This will transfer all of your tags to the remote server that are not already there. Wenn du viele Tags auf einmal hochladen willst, kannst du dem git push Befehl außerdem die --tags Option übergeben und auf diese Weise sämtliche Tags auf den externen Server transferieren, die dort noch nicht bekannt sind. 62

77 Scott Chacon Pro Git Section 3.13 Tips and Tricks $ git push origin --tags Counting objects: 50, done. Compressing objects: 100% (38/38), done. Writing objects: 100% (44/44), 4.56 KiB, done. Total 44 (delta 18), reused 8 (delta 1) To * [new tag] v0.1 -> v0.1 * [new tag] v1.2 -> v1.2 * [new tag] v1.4 -> v1.4 * [new tag] v1.4-lw -> v1.4-lw * [new tag] v1.5 -> v1.5 Now, when someone else clones or pulls from your repository, they will get all your tags as well. Wenn jetzt jemand anderes das Repository klont oder von dort aktualisiert, wird er all diese Tags ebenfalls erhalten Tips and Tricks 3.14 Tipps und Tricks Before we finish this chapter on basic Git, a few little tips and tricks may make your Git experience a bit simpler, easier, or more familiar. Many people use Git without using any of these tips, and we won t refer to them or assume you ve used them later in the book; but you should probably know how to do them. Bevor wir an das Ende dieses Grundlagen Kapitels kommen, noch einige Tipps und Tricks, die dir den Umgang mit Git ein bißchen vereinfachen können. Du kannst Git natürlich einsetzen, ohne diese Tipps anzuwenden, und wir werden später in diesem Buch auch nicht darauf Bezug nehmen oder sie voraussetzen. Aber wir finden, du solltest sie kennen, weil sie einfach nützlich sind Auto-Completion Auto-Vervollständigung If you use the Bash shell, Git comes with a nice auto-completion script you can enable. Download the Git source code, and look in the contrib/completion directory; there should be a file called git-completion.bash. Copy this file to your home directory, and add this to your.bashrc file: Wenn du die Bash Shell verwendest, dann kannst du ein Skript für Git Auto-Vervollständigung einbinden, das mit Git mitgeliefert wird. Wenn du den Git Quellcode heruntergeladen hast, findest du im Verzeichnis contrib/completion die Datei git-completion.bash. Kopiere diese Datei in dein Home Verzeichnis (xxx) und füge die folgende Zeile in deine.bashrc Datei hinzu: source ~/.git-completion.bash 63

78 Chapter 3 Git Grundlagen Scott Chacon Pro Git If you want to set up Git to automatically have Bash shell completion for all users, copy this script to the /opt/local/etc/bash_completion.d directory on Mac systems or to the / etc/bash_completion.d/ directory on Linux systems. This is a directory of scripts that Bash will automatically load to provide shell completions. Wenn du Git Auto-Vervollständigung für alle Benutzer deines Rechners aufsetzen willst, kopiere das Skript in das Verzeichnis /opt/local/etc/bash_completion.d (auf Mac OS X Systemen) bzw. /etc/bash_completion.d/ (auf Linux Systemen). Bash sucht in diesem Verzeichnis nach Erweiterungen für die Autovervollständigung und lädt sie automatisch. If you re using Windows with Git Bash, which is the default when installing Git on Windows with msysgit, auto-completion should be preconfigured. Auf Windows Systemen sollte die Autovervollständigung bereits konfiguriert sein: Git Bash ist standardmäßig installiert, wenn du msysgit verwendest. Press the Tab key when you re writing a Git command, and it should return a set of suggestions for you to pick from: Während du einen Git Befehl tippst, kannst du jetzt die Tab Taste drücken und wirst dann eine Auswahl von Vorschlägen erhalten, aus denen du auswählen kannst: $ git co<tab><tab> commit config In this case, typing git co and then pressing the Tab key twice suggests commit and config. Adding m<tab> completes git commit automatically. D.h., wenn du git co schreibst und dann die Tab Taste zwei Mal drückst, erhältst du die Vorschläge commit und config. Wenn du Tab nur ein Mal drückst, vervollständigt den Befehl deine Eingabe direkt zu git commit. This also works with options, which is probably more useful. For instance, if you re running a git log command and can t remember one of the options, you can start typing it and press Tab to see what matches: Das funktioniert auch mit Optionen - was oftmals noch hilfreicher ist. Wenn du beispielsweise git log verwenden willst und dich nicht an eine bestimmte Option erinnern kannst, schreibst du einfach den Befehl und drückst die Tab Taste, um die Optionen anzuzeigen: $ git log --s<tab> --shortstat --since= --src-prefix= --stat --summary That s a pretty nice trick and may save you some time and documentation reading. Das erspart dir, viel Zeit mit dem Nachschlagen in der Dokumentation zu verbringen Git Aliases Git Aliase Git doesn t infer your command if you type it in partially. If you don t want to type the entire text of each of the Git commands, you can easily set up an alias for each command using git config. Here are a couple of examples you may want to set up: 64

79 Scott Chacon Pro Git Section 3.14 Tipps und Tricks Git versucht nicht, zu erraten, welchen Befehl du verwenden willst, wenn du ihn nur teilweise eingibst. Wenn du lange Befehle nicht immer wieder eintippen willst, kannst du mit git config auf einfache Weise Aliase definieren. Hier einige Beispiele, die du vielleicht nützlich findest: $ git config --global checkout $ git config --global branch $ git config --global commit $ git config --global status This means that, for example, instead of typing git commit, you just need to type git ci. As you go on using Git, you ll probably use other commands frequently as well; in this case, don t hesitate to create new aliases. Das heißt, dass du z.b. einfach git ci anstelle von git commit schreiben kannst. Wenn du Git oft verwendest, werden dir sicher weitere Befehle begegnen, die du sehr oft nutzt. In diesem Fall zögere nicht, weitere Aliase zu definieren. This technique can also be very useful in creating commands that you think should exist. For example, to correct the usability problem you encountered with unstaging a file, you can add your own unstage alias to Git: Diese Technik kann auch dabei helfen, Git Befehle zu definieren, von denen du denkst, es sollte sie geben: $ git config --global alias.unstage 'reset HEAD --' This makes the following two commands equivalent: Das bewirkt, dass die beiden folgenden Befehle äquivalent sind: $ git unstage filea $ git reset HEAD filea This seems a bit clearer. It s also common to add a last command, like this: Das ist etwas klarer, oder? Ein weiterer, typischer Alias ist der last Befehl: $ git config --global alias.last 'log -1 HEAD' This way, you can see the last commit easily: Auf diese Weise kannst Du leicht den letzten Commit nachschlagen: $ git last commit 66938dae3329c7aebe598c2246a8e6af90d04646 Author: Josh Goebel Date: Tue Aug 26 19:48:

80 Chapter 3 Git Grundlagen Scott Chacon Pro Git test for current head Signed-off-by: Scott Chacon As you can tell, Git simply replaces the new command with whatever you alias it for. However, maybe you want to run an external command, rather than a Git subcommand. In that case, you start the command with a! character. This is useful if you write your own tools that work with a Git repository. We can demonstrate by aliasing git visual to run gitk: Wie du dir denken kannst, ersetzt Git ganz einfach den Alias mit dem jeweiligen Befehl, für den er definiert ist. Wenn du allerdings einen externen Befehl anstelle eines Git Subbefehls ausführen willst, kannst du den Befehl mit einem Auführungszeichen (!) anfangen. Das ist in der Regel nützlich, wenn du deine eigenen Hilfsmittel schreibst, um Git zu erweitern. Wir können das demonstrieren, indem wir git visual als gitk definieren: $ git config --global alias.visual "!gitk" 3.15 Summary 3.16 Zusammenfassung At this point, you can do all the basic local Git operations creating or cloning a repository, making changes, staging and committing those changes, and viewing the history of all the changes the repository has been through. Next, we ll cover Git s killer feature: its branching model. Du solltest jetzt in der Lage sein, die wichtigsten Git Befehle einzusetzen und Repositories neu zu erzeugen und zu klonen, Änderungen vorzunehmen und zur Staging Area hinzuzufügen, Commits anzulegen und die Historie aller Commits in einem Repository zu durchsuchen. Als nächstes werden wir auf Gits Killer Feature (xxx) eingehen: das Branching Konzept. 66

81 Chapter 4 Git Branching Fast jedes VCS hat irgendeine Form von branching Unterstützung. Als branching versteht man dabei, die Fähigkeit von der Hauptentwicklungslinie abzuweichen ohne diese zu beeinflussen. Bei vielen VCS ist das ein umständlicher und komplizierter Prozess. Nicht selten ist es notwendig, eine Kopie des kompletten Arbeitsverzeichnisses zu erstellen, was bei grossen Projekten eine Weile dauern kann. Nearly every VCS has some form of branching support. Branching means you diverge from the main line of development and continue to do work without messing with that main line. In many VCS tools, this is a somewhat expensive process, often requiring you to create a new copy of your source code directory, which can take a long time for large projects. Es gibt Leute, die bezeichnen das branching Modell in Git als sein killer feature, weshalb sich Git dadurch zweifellos innerhalb der VCS Community abhebt. Aber warum ist es so besonders? Die Art wie Git Branches behandelt ist unglaublich leichtgewichtig, macht das branching dadurch blitzschnell und ermöglicht so einfaches vor und zurück Schalten der einzelnen Versionen. Anders als andere VCS ermutigt Gít ausdrücklich zur Verwendung von häufigem branching und merging. Das Verständnis und die Fähigkeit im Umgang mit diesem Feature gibt dir ein machtvolles und einzigartiges Werkzeug in die Hand, dass deinen Weg zu entwicklen buchstäblich ändern wird. Some people refer to the branching model in Git as its killer feature, and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages a workflow that branches and merges often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can literally change the way that you develop. 4.1 Was eine Branch ist 4.2 What a Branch Is Um den Weg des branching in Git richtig zu verstehen, müssen wir eine Schritt zurück machen und untersuchen, wie Git die Daten speichert. Wie du sicher noch aus Kapitel 1 weisst, speichert Git nicht eine Reihe von Änderungen und Unterschiede, sondern immer in Form von Snapshots, also aktuelle Sichten auf den Code. To really understand the way Git does branching, we need to take a step back and examine how Git stores its data. As you may remember from Chapter 1, Git doesn t store data as a series of changesets or deltas, but instead as a series of snapshots. 67

82 Chapter 4 Git Branching Scott Chacon Pro Git Wenn du ein Commit durchführst, speichert Git ein Commit-Objekt, das einen Pointer auf die aktuelle Sicht des geänderten Inhalts besitzt. Gleichzeitig wird der Autor, einige zusätzliche Informationen und kein oder mehrere Pointer auf die direkten Elternteile dieses Commits abgespeichert: kein Pointer für den ersten Commit, ein Pointer für ein normales Commit und mehrere Pointer für ein Commit, dass auf Basis eines merge von ein oder mehreren branches durchgeführt wurde. When you commit in Git, Git stores a commit object that contains a pointer to the snapshot of the content you staged, the author and message metadata, and zero or more pointers to the commit or commits that were the direct parents of this commit: zero parents for the first commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches. Um das zu verdeutlichen, lass uns annehmen, du hast ein Verzeichnis mit drei Dateien, die du alle markierst und commitest. Das Markieren der Dateien erzeugt für jede eine Prüfsumme (der SHA-1 Hash, der ebenfalls in Kapitel 1 erwähnt wurde), speichert diese Version der Datei im Git Repository (Git referenziert auf diese als Blobs) und fügt diese Prüfsumme der markierten Ebene hinzu: To visualize this, let s assume that you have a directory containing three files, and you stage them all and commit. Staging the files checksums each one (the SHA-1 hash we mentioned in Chapter 1), stores that version of the file in the Git repository (Git refers to them as blobs), and adds that checksum to the staging area: $ git add README test.rb LICENSE2 $ git commit -m 'initial commit of my project' Wenn du ein Commit mit dem Kommando git commit erstellst, erzeugt Git für jedes Unterverzeichnis eine Pürfsumme (in diesem Fall nur für das Root-Verzeichnis) und speichert diese drei Objekte im Git Repository. Git erzeugt dann ein Commit Objekt, das die Metadaten und den Pointer zur Wurzel des Projektbaums, um bei Bedarf den Snapshot erneut erzeugen zu können. When you create the commit by running git commit, Git checksums each subdirectory (in this case, just the root project directory) and stores those tree objects in the Git repository. Git then creates a commit object that has the metadata and a pointer to the root project tree so it can re-create that snapshot when needed. Dein Git Repository enthält nun fünf Objekte: einen Blob für den Inhalt jeder der drei Dateien, einen Baum, der den Inhalt des Verzeichnisses auflistet und spezifiziert, welcher Dateiname zu welchem Blob gehört, und einen Pointer, der auf die Wurzel des Projektbaums verweist und alle Metadaten des Commits. Dem Bgriff nach können deine Daten im Git Repository wie in Abbildung 3-1 aussehen. Your Git repository now contains five objects: one blob for the contents of each of your three files, one tree that lists the contents of the directory and specifies which file names are stored as which blobs, and one commit with the pointer to that root tree and all the commit metadata. Conceptually, the data in your Git repository looks something like Figure 3.1. Wenn du erneut etwas änderst und wieder ein Commit machst, wird dieses einen Pointer speichern, der auf das vorhergehende verweist. Nach zwei weiteren Commits könnte die Historie wie in Abbildung 3-2 aussehen. If you make some changes and commit again, the next commit stores a pointer to the commit that came immediately before it. After two more commits, your history might look something like Figure 3.2. Eine Branch in Git ist nichts anderes als ein leichtgewichtiger Pointer auf eines dieser Commits. Der Standardname für eine Branch in Git ist master. Mit dem initialen Commit erhältst du eine master branch, die auf dein letztes Commit zeigt. Mit jedem Commit wird bewegt sie sich automatisch 68

83 Scott Chacon Pro Git Section 4.2 What a Branch Is Figure 4.1: Repository-Daten eines einzelnen Commits Figure 3.1. Single commit repository data Figure 4.2: Git Objektdaten für mehrere Commits Figure 3.2. Git object data for multiple commits vorwärts. A branch in Git is simply a lightweight movable pointer to one of these commits. The default branch name in Git is master. As you initially make commits, you re given a master branch that points to the last commit you made. Every time you commit, it moves forward automatically. Figure 4.3: Branch-Pointer in die Commit Datenhistorie Figure 3.3. Branch pointing into the commit data s history Was passiert, wenn du eine neue Branch erstellst? Zunächst wird ein neuer Pointer erstellt. Sagen wir, du hast eine neue Branch mit dem Namen testing erstellt. Das machst du mit dem git branch Befehl: What happens if you create a new branch? Well, doing so creates a new pointer for you to move around. Let s say you create a new branch called testing. You do this with the git branch command: 69

84 Chapter 4 Git Branching Scott Chacon Pro Git $ git branch testing Dies erzeugt einen neuen Pointer auf das gleiche Commit auf dem du gerade arbeitest (Abbildung 3-4). This creates a new pointer at the same commit you re currently on (see Figure 3.4). Figure 4.4: Mehrere Branches zeigen in die Commit Datenhistorie Figure 3.4. Multiple branches pointing into the commit s data history Woher weiß Git, welche Branch du momentan verwendest? Dafür gibt es einen speziellen Pointer mit dem Namen HEAD. Berücksichtige, dass dieses grundsätzlich anders als die HEAD-Konzepten anderer VCS, wie Subversion oder CVS, funktioniert. Bei Git handelt es sich hierbei um einen Pointer deiner aktuellen lokalen Branch. In dem Fall bist du immer noch auf der master Branch. Das git branch Kommando hat nur einen neue Branch erstellt, aber nicht dahin umgeschaltet (Abbildung 3-5). How does Git know what branch you re currently on? It keeps a special pointer called HEAD. Note that this is a lot different than the concept of HEAD in other VCSs you may be used to, such as Subversion or CVS. In Git, this is a pointer to the local branch you re currently on. In this case, you re still on master. The git branch command only created a new branch it didn t switch to that branch (see Figure 3.5). Figure 4.5: HEAD Datei zeigt auf die von dir benutzte Branch Figure 3.5. HEAD file pointing to the branch you re on Um zu einen anderen Branch zu wechseln, benutze das Kommando git checkout. Lass uns zur neue testing Branch wechseln: To switch to an existing branch, you run the git checkout command. Let s switch to the new testing branch: $ git checkout testing Das lässt HEAD nun auf die testing Branch verweisen (siehe auch Abbildung 3-6). This moves HEAD to point to the testing branch (see Figure 3.6). 70

85 Scott Chacon Pro Git Section 4.2 What a Branch Is Figure 4.6: HEAD zeigt auf eine andere Branch, wenn man diese gewechselt hat. Figure 3.6. HEAD points to another branch when you switch branches. Wofür benötigt man das? Ok, lass uns ein anderes commit machen: What is the significance of that? Well, let s do another commit: $ vim test.rb $ git commit -a -m 'made a change' Abbildung 3-7 verdeutlich das Ergebnis. Figure 3.7 illustrates the result. Figure 4.7: Die Branch, auf die HEAD zeigt, bewegt sich mit jedem commit nach vorn. Figure 3.7. The branch that HEAD points to moves forward with each commit. Das Interessante daran ist, dass sich jetzt deine testing Branch vorwärts bewegt hat und die master immer noch auf den commit verweist bevor du mit git checkout gewechselt hast. Lass uns zurück zu master wechseln: This is interesting, because now your testing branch has moved forward, but your master branch still points to the commit you were on when you ran git checkout to switch branches. Let s switch back to the master branch: $ git checkout master Abbildung 3-8 zeigt das Ergebnis. Figure 3.8 shows the result. Dieses Kommando macht zwei Dinge. Es veranlasst den HEAD Pointer zurück auf die master Branch zu zeigen und es setzt die Dateien in deinem Arbeitsverzeichnis zurück z udem Zeitpunkt, als der letzte master Snapshot gemacht wurde. Das heißt auch, dass alle Änderungen, die du ab jetzt machst, auf Basis eines älteren Standes des Projekts erfolgen. Es setzt grundsätzlich alle Änderungen der testing Branch vorübergehend zurück und gibt dir die Möglichkeit, einen ganz anderen Weg in 71

86 Chapter 4 Git Branching Scott Chacon Pro Git Figure 4.8: HEAD zeigt auf eine andere Branch, wenn checkout verwendet wurde. Figure 3.8. HEAD moves to another branch on a checkout. der Entwicklung einzuschlagen. That command did two things. It moved the HEAD pointer back to point to the master branch, and it reverted the files in your working directory back to the snapshot that master points to. This also means the changes you make from this point forward will diverge from an older version of the project. It essentially rewinds the work you ve done in your testing branch temporarily so you can go in a different direction. Lass uns ein paar Änderungen machen und diese per commit festhalten: Let s make a few changes and commit again: $ vim test.rb $ git commit -a -m 'made other changes' Jetzt läuft dein Projekt auseinander (siehe Abbildung 3-9). Du hast eine Branch angelegt, zu ihr gewechselt, einen Änderungen vorgenommen und wieder zurück zu deiner Haupt-Branch geschaltet und etwas anderes geändert. Beide Änderungswege sind von einander isoliert in eigene Branches: du kannst hin und her schalten und sie zusammenführen, wenn du denkst, dass es soweit ist. Und das alles mit den einfachen Kommandos branch und checkout. Now your project history has diverged (see Figure 3.9). You created and switched to a branch, did some work on it, and then switched back to your main branch and did other work. Both of those changes are isolated in separate branches: you can switch back and forth between the branches and merge them together when you re ready. And you did all that with simple branch and checkout commands. Figure 4.9: Die Branch-Historie läuft auseinander. Figure 3.9. The branch histories have diverged. Eine Branch in Git ist eine einfache Datei, die nur die 40 Zeichen lange SHA-1 Prüfsumme des Commits enthält, auf das sie zeigt. Es kostet nicht viel, Branches zu erstellen und zu zerstören. Das Erstellen einer Branch ist der einfache und schnelle Weg, 41 Bytes in eine Datei zu schreiben (40 Zeichen für die Prüdsumme und ein Zeilenumbruch). Because a branch in Git is in actuality a simple file that contains the 40 character SHA-1 checksum of the commit it points to, branches are cheap 72

87 Scott Chacon Pro Git Section 4.3 Basic Branching and Merging to create and destroy. Creating a new branch is as quick and simple as writing 41 bytes to a file (40 characters and a newline). Das steht im krassen Kontrast zum Weg den andere VCS Tools zum Thema Branch einschlagen. Vielfach ist ein Kopieren aller Projekt-Dateien in ein anderes Verzeichnis damit verbunden. Das kann einige Zeit in Anspruch nehmen und hängt von der Größe des Projektes ab. In Git geht das blitzschnell. Genauso, weil wir immer auch den Ursprung bem Commit mit aufzeichnen, haben wir automatisch eine gute Basis zum Zusammenführen verschiedner Zweige. Damit soll es Entwicklern erleichtert werden, Branches viel einzusetzen. This is in sharp contrast to the way most VCS tools branch, which involves copying all of the project s files into a second directory. This can take several seconds or even minutes, depending on the size of the project, whereas in Git the process is always instantaneous. Also, because we re recording the parents when we commit, finding a proper merge base for merging is automatically done for us and is generally very easy to do. These features help encourage developers to create and use branches often. Lass uns anschauen, wie du das machen kannst. Let s see why you should do so. 4.3 Basic Branching and Merging Lass uns das Ganze an einem Beispiel durchgehen, dessen Workflow zum Thema Branching und Zusammenführen du im echten Leben verwenden kannst. Folge einfach diesen Schritten: Let s go through a simple example of branching and merging with a workflow that you might use in the real world. You ll follow these steps: 1. Arbeite an einer Webseite. 2. Erstell eine Branch für eine neue Geschichte an der du arbeitest. 3. Arbeite an dieser Branch. 4. Do work on a web site. 5. Create a branch for a new story you re working on. 6. Do some work in that branch. In diesem Augenblick kommt ein Anruf, dass ein anderes Problem sehr kritisch ist und sofort gelöst werden muss. Du machst folgendes: At this stage, you ll receive a call that another issue is critical and you need a hotfix. You ll do the following: 1. Geh zurück auf deine produktive Branch. 2. Erstelle eine Branch für den Hotfix. 3. Nach dem Testen führst du die Hotfix-Branch mit der Produktion-Branch zusammen. 4. Schalte jetzt wieder auf deine Origialstory zurück und setze deine Arbeit fort. 5. Revert back to your production branch. 6. Create a branch to add the hotfix. 7. After it s tested, merge the hotfix branch, and push to production. 8. Switch back to your original story and continue working. 73

88 Chapter 4 Git Branching Scott Chacon Pro Git Branching Grundlagen Basic Branching Sagen wir, du arbeitest an deinem Projekt und hast bereits einige Commits durchgeführt (siehe Abbildung 3-10). First, let s say you re working on your project and have a couple of commits already (see Figure 3.10). Figure 4.10: Eine kurze, einfache Commit-Historie Figure A short and simple commit history Du hast dich dafür entschieden an dem Issue #53, des Issue-Trackers XY, zu arbeiten. Um eines klarzustellen, Git ist an kein Issue-Tracking-System gebunden. Da der Issue #53 allerdings ein Schwerpunktthema betrifft, wirst du einen neuen Branch erstellen um daran zu arbeiten. Um in einem Arbeitsschritt einen neuen Branch zu erstellen und zu aktivieren kannst du das Kommando git checkout mit der Option -b verwenden: Du hast dich entschiden, am Issue #53 des Issue-Tracking-Systems XYZ deiner Firma zuarbeiten. Um es klarzustellen: Git ist an kein spezifisches Issue-Tracking-Systems gebunden, aber weil Issue #53 ein wichtiges Thema ist, willst du daran arbeiten und erstellst eine neue Branch, um daran zu arbeiten. Um die Branch zu erstellen und gleichzeitig zu ihr umzuschalten, kannst du das Kommando git checkout in Verbindung mitder Option -b verwenden: You ve decided that you re going to work on issue #53 in whatever issue-tracking system your company uses. To be clear, Git isn t tied into any particular issue-tracking system; but because issue #53 is a focused topic that you want to work on, you ll create a new branch in which to work. To create a branch and switch to it at the same time, you can run the git checkout command with the -b switch: $ git checkout -b iss53 Switched to a new branch "iss53" Das ist die Kurzform von This is shorthand for $ git branch iss53 $ git checkout iss53 Abbildung 3-11 verdeutlicht das Ergebnis. Figure 3.11 illustrates the result. Du arbeitest an deiner Web-Seite und machst ein paar Commits. Das bewegt den iss53-branch vorwärts, da du ihn ausgebucht hast (das heißt, dass dein HEAD-Zeiger darauf verweist; siehe Abbildung 3-12): Du arbeitest an deiner Web-Site und machst ein paar Commits. Dabei bewegt sich die iss53 Branch vorwärts, da sie gerade deine aktuelle Branch ist (der HEAD Pointer verweist 74

89 Scott Chacon Pro Git Section 4.3 Basic Branching and Merging Figure 4.11: Erstellung eines neuen Branch-Zeigers Figure Creating a new branch pointer darauf, siehe Abbildung 3-12): You work on your web site and do some commits. Doing so moves the iss53 branch forward, because you have it checked out (that is, your HEAD is pointing to it; see Figure 3.12): $ vim index.html $ git commit -a -m 'added a new footer [issue 53]' Figure 4.12: Der iss53-branch hat mit deiner Arbeit Schritt gehalten. Figure The iss53 branch has moved forward with your work. Nun bekommst du einen Anruf in dem dir mitgeteilt wird, dass es ein Problem mit der Internet- Seite gibt, welches du umgehend beheben sollst. Mit Git musst du deine Fehlerkorrektur nicht zusammen mit den iss53-änderungen einbringen. Und du musst keine Zeit damit verschwenden deine bisherigen Änderungen rückgängig zu machen, bevor du mit der Fehlerbehebung an der Produktionsumgebung beginnen kannst. Alles was du tun musst, ist zu deinem MASTER-Branch wechseln. Jetzt bekommst du einen Anruf, dass es ein Problem mit der Website gibt, und du musst es umgehend beheben. Mit Git musst die Problembehebung nicht zusammen mit der Arbeit an iss53 einspielen, und du musst auch keinen Aufwand in das Zurücksetzen der Änderungen stecken, bevor du die Problembehebung in die Produktion einspielen kannst. Alles was du machen musst, ist zurück zur master Branch schalten. Now you get the call that there is an issue with the web site, and you need to fix it immediately. With Git, you don t have to deploy your fix along with the iss53 changes you ve made, and you don t have to put a lot of effort into reverting those changes before you can work on applying your fix to what is in production. All you have to do is switch back to your master branch. Beachte jedoch, dass dich Git den Branch nur wechseln lässt wenn bisherige Änderungen in deinem Arbeitsverzeichnis oder deiner Staging Area nicht in Konflikt mit dem Zweig stehen zu dem du nun wechseln möchtest. Am besten es liegt ein sauberer Status vor wenn man den Branch wechselt. Wir werden uns später mit Wegen befassen, dieses Verhalten zu umgehen (namentlich Stashing 75

90 Chapter 4 Git Branching Scott Chacon Pro Git und Commit Ammending). Vorerst hast du deine Änderungen bereits comitted, sodass du zu deinem MASTER-Branch zurückwechseln kannst. Wie auch immer, bevor du das machst, ein Hinweis, wenn du nicht committete Sachen in deinem Arbeits- oder Staging-Verzeichnis hast, die einen Konflikt mit der Branch, zu der du schalten willst, hat, lässt dich Git nicht dorthin schalten. Am besten man hat einen sauberen Arbeitsstand, wenn man die Branch wechseln will. Es gibt Wege, um das zu umgehen (stashing und commit amending). Aber dazu später mehr. Im Moment solltest du deine Änderungen committen und dann zur master Branch wechseln: However, before you do that, note that if your working directory or staging area has uncommitted changes that conflict with the branch you re checking out, Git won t let you switch branches. It s best to have a clean working state when you switch branches. There are ways to get around this (namely, stashing and commit amending) that we ll cover later. For now, you ve committed all your changes, so you can switch back to your master branch: $ git checkout master Switched to branch "master" Zu diesem Zeitpunkt befindet sich das Arbeitsverzeichnis des Projektes in exakt dem gleichen Zustand, in dem es sich befand als du mit der Arbeit an Issue #53 begonnen hast und du kannst dich direkt auf deinen Hotfix konzentrieren. Dies ist ein wichtiger Moment um sich vor Augen zu halten, dass Git dein Arbeitsverzeichnis auf den Zustand des Commits, auf den dieser Branch zeigt, zurücksetzt. Es erstellt, entfernt und verändert Dateien automatisch, um sicherzustellen das deine Arbeitskopie haargenau so aussieht wie der Zweig nach deinem letzten Commit. An dieser Stelle befindet sich dein Projekt Arbeitsverzeichnis an exakt der gleichen Stelle, wie vor der Arbeit an iss53, und du kannst dich auf den Hotfix konzentrieren. Das ist ein wichtiger Aspekt, den man im Kopf behalten sollte: Git setzt dein Arbeitsverzeichnis immer auf den Stand, der dem Snapshot der aktuellen Branch entspricht. Es werden automatisch die entsprechenden Dateien hinzugefügt, gelöscht und modifiziert, damit die Arbeitskopie, wie nach deinem letzten Commit in dieser Branch aussieht. At this point, your project working directory is exactly the way it was before you started working on issue #53, and you can concentrate on your hotfix. This is an important point to remember: Git resets your working directory to look like the snapshot of the commit that the branch you check out points to. It adds, removes, and modifies files automatically to make sure your working copy is what the branch looked like on your last commit to it. Nun hast du einen Hotfix zu erstellen. Kass uns dazu einen Hotfix-Branch erstellen an dem du bis zu seiner Fertigstellung arbeitest (siehe Abbildung 3-13): Als nächstes hast du einen Hotfix zu machen. Lass uns eine Hotfix Branch erstellen, an der du bis zur Fertigstellung arbeitest (siehe Abbildung 3-13): Next, you have a hotfix to make. Let s create a hotfix branch on which to work until it s completed (see Figure 3.13): $ git checkout -b 'hotfix' Switched to a new branch "hotfix" $ vim index.html $ git commit -a -m 'fixed the broken address' [hotfix]: created 3a0874c: "fixed the broken address" 1 files changed, 0 insertions(+), 1 deletions(-) 76

91 Scott Chacon Pro Git Section 4.3 Basic Branching and Merging Figure 4.13: Der Hotfix-Branch basiert auf dem zurückliegenden Master-Branch. Abbildung Hotfix Branch verweist auf die master Branch zurück Figure hotfix branch based back at your master branch point Mach deine Tests, stell sicher, dass sich der Hotfix verhält wie gewünscht und führe ihn mit dem Master-Branch zusammen um ihn in die Produktionsumgebung zu integrieren. Das machst du mit dem git merge-kommando: Mach deine Tests, stell sicher, dass der Hotfix das macht, was du willst und führe ihn mit der master Branch zusammen, um diese wieder in die Produktion zu bringen. Du machst das mit dem Kommando git merge: You can run your tests, make sure the hotfix is what you want, and merge it back into your master branch to deploy to production. You do this with the git merge command: $ git checkout master $ git merge hotfix Updating f42c576..3a0874c Fast forward README 1-1 files changed, 0 insertions(+), 1 deletions(-) Du wirst die Mitteilung Fast Forward während des Zusammenführens bemerken. Da der neue Commit direkt von dem ursprünglichen Commit, auf den sich der nun eingebrachte Zweig bezieht, abstammt, bewegt Git einfach den Zeiger weiter. Mit anderen Worten, kann Git den neuen Commit, durch verfolgen der Commitabfolge, direkt erreichen, dann bewegt es ausschließlich den Branch- Zeiger. Zu einer tatsächlichen Kombination der Commits besteht ja kein Anlass. Dieses Vorgehen wird Fast Forward genannt. Hast du die Nachricht Fast forward beim Zusammenführen gesehen? Da du auf die aktuelle Branch aufgesetzt hast und die Änderung eine direkte Weiterführung dieser war, hat Git den Pointer weitergestellt. Anders ausgedrückt, wenn zwischen zwei Branches kein Unterschied besteht oder nur eine davon eine Weiterentwicklung darstellt, bringt Git diese beiden wieder auf Linie - das wird dann fast forward genannt. You ll notice the phrase Fast forward in that merge. Because the commit pointed to by the branch you merged in was directly upstream of the commit you re on, Git moves the pointer forward. To phrase that another way, when you try to merge one commit with a commit that can be reached by following the first commit s history, Git simplifies things by moving the pointer forward because there is no divergent work to merge together this is called a fast forward. 77

92 Chapter 4 Git Branching Scott Chacon Pro Git Deine Modifikationen befinden sich nun als Schnappschuss in dem Commit, auf den der master-branch zeigt, diese lassen sich nun veröffentlichen (siehe Abbildung 3-14). Deine Änderung befindet sich nun in dem commit-snapshot der auf die master Branch zeigt und du kannst ein deploy deiner Änderungen durchführen (siehe Abbildung 3-14). Your change is now in the snapshot of the commit pointed to by the master branch, and you can deploy your change (see Figure 3.14). Figure 4.14: Der Master-Branch zeigt nach der Zusammenführung auf den gleichen Commit wie der Hotfix- Branch. Abbildung Dein Master-Branch zeigt, nach dem Merge, auf den gleichen Commit, wie der Hotfix-Branch. Figure Your master branch points to the same place as your hotfix branch after the merge. Nachdem dein superwichtiger Hotfix veröffentlicht wurde kannst du dich wieder deiner ursprünglichen Arbeit zuwenden. Vorher wird sich allerdings des nun nutzlosen Hotfix-Zweiges entledigt, schließlich zeigt der Master-Branch ebenfalls auf die aktuelle Version. Du kannst ihn mit der -d-option von git branch entfernen: Nachdem du den super wichtigen Fix erstellt hast, kannst du mit der Arbeit weiter zu machen, die du zuvor angefangen hast. Als erstes kannst du den hotfix-branch löschen, da er nicht länger benötigt wird - der master-branch zeigt auf die gleiche Version. Den Branch kannst du mit der -d-option, angehängen an git branch, löschen: After that your super-important fix is deployed, you re ready to switch back to the work you were doing before you were interrupted. However, first you ll delete the hotfix branch, because you no longer need it the master branch points at the same place. You can delete it with the -d option to git branch: $ git branch -d hotfix Deleted branch hotfix (3a0874c). Nun kannst du zu deinem Issue #53-Branch zurückwechseln und mit deiner Arbeit fortfahren (Abbildung 3-15): Nun kannst du zurück auf deinen Work-In-Progress -Branch, Issue #53, wechseln und mit deiner Arbeit weiter machen (Abbildung 3-15): Now you can switch back to your work-in-progress branch on issue #53 and continue working on it (see Figure 3.15): $ git checkout iss53 Switched to branch "iss53" $ vim index.html $ git commit -a -m 'finished the new footer [issue 53]' 78

93 Scott Chacon Pro Git Section 4.3 Basic Branching and Merging [iss53]: created ad82d7a: "finished the new footer [issue 53]" 1 files changed, 1 insertions(+), 0 deletions(-) Insert 18333fig0315.png Dein iss53-branch kann sich unabhängig weiterentwickeln. Abbildung Deine iss53 Branch kann sich unabhängig weiter entwickeln. Figure Your iss53 branch can move forward independently. An dieser Stelle ist anzumerken, dass die Änderungen an dem hotfix-branch nicht in deinen iss53-zweig eingeflossen sind. Falls nötig kannst du den master-branch allerdings mit dem Kommando git merge master mit deinem Zweig kombinieren. Oder du wartest bis du den iss53-branch später in den Master-Zweig zurückführst. It s worth noting here that the work you did in yourhotfixbranch is not contained in the files in youriss53branch. If you need to pull it in, you can merge yourmasterbranch into youriss53branch by runninggit merge master, or you can wait to integrate those changes until you decide to pull theiss53branch back intomaster later Die Grundlagen des Zusammenführens (Mergen) Basic Merging Angenommen du entscheidest dich, dass deine Arbeit an issue #53 getan ist und du diese mit der master Branch zusammenführen möchtest. Das passiert, indem du ein merge in die iss53 Branch machst, ähnlich dem merge mit der hotfix Branch von vorhin. Alles was du machen musst, ist ein checkout der Branch, in die du das merge machen willst und das Ausführen des Kommandos git merge: Suppose you ve decided that your issue #53 work is complete and ready to be merged into your master branch. In order to do that, you ll merge in your iss53 branch, much like you merged in your hotfix branch earlier. All you have to do is check out the branch you wish to merge into and then run the git merge command: $ git checkout master $ git merge iss53 Merge made by recursive. README files changed, 1 insertions(+), 0 deletions(-) Das sieht ein bisschen anders aus als das hotfix merge von vorhin. Hier läuft deine Entwicklungshistorie auseinander. Ein commit auf deine Arbeits-Branch ist kein direkter Nachfolger der Branch in die du das merge gemacht hast, Git hat da einiges zu tun, es macht einen 3-Wege merge: es geht von den beiden snapshots der Branches und dem allgemeinen Nachfolger der beiden aus. Abbildung 3-16 zeigt die drei snapshots, die Git in diesem Fall für das merge verwendet. This looks a bit different than the hotfix merge you did earlier. In this case, your development history has diverged from some older point. Because the commit on the branch you re on isn t a direct ancestor of the branch you re merging in, Git has to do some work. In this case, Git does a simple three-way merge, using the two snapshots pointed to by the branch tips and the common ancestor of the two. Figure 3.16 highlights the three snapshots that Git uses to do its merge in this case. 79

94 Chapter 4 Git Branching Scott Chacon Pro Git Figure 4.15: Git ermittelt automatisch die beste Nachfolgebasis für die Branchzusammenführung. Figure Git automatically identifies the best common-ancestor merge base for branch merging. Anstatt einfach den pointer weiterzubewegen, erstellt Git einen neuen snapshot, der aus dem 3-Wege merge resultiert und erzeugt einen neuen commit, der darauf verweist (siehe Abbildung 3-17). Dies wird auch als merge commit bezeichnet und ist ein Spezialfall, weil es mehr als nur ein Elternteil hat. Instead of just moving the branch pointer forward, Git creates a new snapshot that results from this three-way merge and automatically creates a new commit that points to it (see Figure 3.17). This is referred to as a merge commit and is special in that it has more than one parent. Es ist wichtig herauszustellen, dass Git den besten Nachfolger für die merge Basis ermittelt, denn hierin unterscheidet es sich von CVS und Subversion (vor Version 1.5), wo der Entwickler die merge Basis selbst ermitteln muss. Damit wird das Zusammenführen um einiges leichter in Git als in anderen Systemen. It s worth pointing out that Git determines the best common ancestor to use for its merge base; this is different than CVS or Subversion (before version 1.5), where the developer doing the merge has to figure out the best merge base for themselves. This makes merging a heck of a lot easier in Git than in these other systems. Figure 4.16: Git erstellt automatisch ein commit, dass die zusammengeführte Arbeit enthält. Figure Git automatically creates a new commit object that contains the merged work. Jetzt da wir die Arbeit zusammengeführt haben, ist die iss53 Branch nicht mehr notwendig. Du kansst sie löschen und das Ticket im ticket-tracking System schliessen. Now that your work is merged in, you have no further need for the iss53 branch. You can delete it and then manually close the ticket in your ticket-tracking system: $ git branch -d iss Grundlegende merge Konflikte Basic Merge Conflicts Gelegentlich verläuft der Prozess nicht ganz so glatt. Wenn du an den selben Stellen in den selben Dateien unterschiedlicher Branches etwas geändert hast, kann Git diese nicht sauber zusammenführen. Wenn dein Fix an issue #53 die selbe Stelle in einer Datei verändert hat, die du auch mit hotfix angefasst hast, wirst du einen merge Konflikt erhalten, der ungefähr so aussehen könnte: Occasionally, this process doesn t go smoothly. If you changed the same part of the same file differently in the two branches you re merging together, Git won t be able to merge them cleanly. If your fix for issue #53 modified the same part of a file as the hotfix, you ll get a merge conflict that looks something like this: 80

95 Scott Chacon Pro Git Section 4.3 Basic Branching and Merging $ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. Git hat hier keinen merge commit erstellt. Es hat den Prozess gestoppt, damit du den Konflikt beseitigen kannst. Wenn du sehen willst, welche Dateien unmerged aufgrund eines merge Konflikts sind, benutze einfach git status: Git hasn t automatically created a new merge commit. It has paused the process while you resolve the conflict. If you want to see which files are unmerged at any point after a merge conflict, you can run git status: [master*]$ git status index.html: needs merge # On branch master # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # unmerged: index.html # Alles, was einen merge Konflikt aufweist und nicht gelöst werden konnte, wird als unmerged aufgeführt. Git fügt Standard-Konfliktlösungsmarker den betroffen Dateien hinzu, so dass du diese öffnen und den Konflikt manuell lösen kannst. Deine Datei enthält einen Bereich, der so aussehen könnte: Anything that has merge conflicts and hasn t been resolved is listed as unmerged. Git adds standard conflict-resolution markers to the files that have conflicts, so you can open them manually and resolve those conflicts. Your file contains a section that looks something like this: <<<<<<< HEAD:index.html <div id="footer">contact : ======= <div id="footer"> please contact us at </div> >>>>>>> iss53:index.html Das heisst, die Version in HEAD (deiner master Branch, denn die wurde per checkout aktiviert, als du das merge gemacht hast) ist der obere Teil des Blocks (alles oberhalb von ======= ), und die Version aus der iss53 Branch sieht wie der darunter befindliche Teil aus. Um den Konflikt zu lösen, musst du dich entweder für einen der beiden Teile entscheiden oder du ersetzt den Teil komplett: This means the version in HEAD (your master branch, because that was what you had checked out when you ran your merge command) is the top part of that block (everything above the =======), while the version in your iss53 branch looks like everything in the bottom part. In order to resolve the conflict, you have to either choose one side or the other or merge the contents yourself. For instance, you might resolve this conflict by replacing the entire block with this: 81

96 Chapter 4 Git Branching Scott Chacon Pro Git <div id="footer"> please contact us at </div> Diese Lösung hat von allen Bereichen etwas und ich habe die Zeilen mit <<<<<<<, =======, und >>>>>>> komplett gelöscht. Nachdem du alle problematischen Bereiche in allen durch den Konflikt betroffenen Dateien beseitigt hast, mach einfach git add für alle betroffenen Dateien und markieren sie damit als bereinigt. Dieses staging der Dateien markiert sie für Git als bereinigt. Wenn du ein graphischen Tool zur Bereinigung benutzen willst, verwende git mergetool, welches ein empfohlenes graphisches merge Tool startet und dich durch die Konfliktbereiche führt: This resolution has a little of each section, and I ve fully removed the <<<<<<<, =======, and >>>>>>> lines. After you ve resolved each of these sections in each conflicted file, run git add on each file to mark it as resolved. Staging the file marks it as resolved in Git. If you want to use a graphical tool to resolve these issues, you can run git mergetool, which fires up an appropriate visual merge tool and walks you through the conflicts: $ git mergetool merge tool candidates: kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff Merging the files: index.html Normal merge conflict for 'index.html': {local}: modified {remote}: modified Hit return to start merge resolution tool (opendiff): Wenn du ein anderes als das Standardwerkzeug für ein merge verwenden möchtest (Git verwendet opendiff in meinem Fall, da ich auf einem Mac arbeite), kannst du alle unterstützten Werkzeuge oben direkt neben merge tool candidates aufgelistet sehen. Tippe einfach den Namen deines Werkzeugs ein. In Kapitel 7 besprechen wir, wie du diesen Standardwert in deiner Umgebung ändern kannst. If you want to use a merge tool other than the default (Git chose opendiff for me in this case because I ran the command on a Mac), you can see all the supported tools listed at the top after merge tool candidates. Type the name of the tool you d rather use. In Chapter 7, we ll discuss how you can change this default value for your environment. Wenn du das merge Werkzeug beendest, fragt dich Git, ob das Zusammenführen erfolgreich war. Wenn du mit Ja antwortest, wird das Skript diese Dateien als gelöst markieren. After you exit the merge tool, Git asks you if the merge was successful. If you tell the script that it was, it stages the file to mark it as resolved for you. Du kannst git status erneut ausführen, um zu sehen, ob alle Konflikte gelöst sind: You can run git status again to verify that all conflicts have been resolved: $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) 82

97 Scott Chacon Pro Git Section 4.4 Branch Management # # modified: index.html # Wenn du zufrieden bist und du geprüft hast, dass alle Konflikte beseitigt wurden, kannst du ein git commit ausführen um das merge commit abzuschliessen. Die Standardbeschreibung für diese Art commit sieht wie folgt aus: If you re happy with that, and you verify that everything that had conflicts has been staged, you can type git commit to finalize the merge commit. The commit message by default looks something like this: Merge branch 'iss53' Conflicts: index.html # # It looks like you may be committing a MERGE. # If this is not correct, please remove the file #.git/merge_head # and try again. # Du annst diese Beschreibung mit eigenen Details modifizieren, wie du zum Beispiel das Zusammenführen gelöst hast, wenn du meinst es könnte auch für andere interessant sein, die sich dieses merge in Zukunft anschauen - warum du was getan hast, wenn es nicht offensichtlich ist. You can modify that message with details about how you resolved the merge if you think it would be helpful to others looking at this merge in the future why you did what you did, if it s not obvious. 4.4 Branch Management Du weißt jetzt, wie du Branches erstellen, mergen und löschen kannst. Wir schauen uns jetzt noch ein paar recht nützliche Tools für die Arbeit mit Branches an. Das Kommando git branch kann mehr, als nur Branches zu erstellen oder zu löschen. Wenn du es ohne weitere Argumente ausführst, wird es dir eine Liste mit deinen aktuellen Branches anzeigen: $ git branch iss53 * master testing Das * vor dem master-branch bedeutet, dass dies der gerade ausgecheckte Branch ist. Wenn du also jetzt einen Commit erzeugst, wird dieser in den master-branch gehen. Du kannst dir mit git branch -v ganz schnell für jeden Branch den letzten Commit anzeigen lassen: 83

98 Chapter 4 Git Branching Scott Chacon Pro Git $ git branch -v iss53 93b412c fix javascript issue * master 7a98805 Merge branch 'iss53' testing 782fd34 add scott to the author list in the readmes Mit einer weiteren nützlichen Option kannst du herausfinden, in welchem Zustand deine Branches sind: welche der Branches wurden bereits in den aktuellen Branch gemergt und welche wurden es nicht. Die Optionen heißen --merged und --no-merged und sind seit Version in Git dabei. Um herauszufinden, welche Branches schon in den aktuell ausgecheckten gemergt wurden, kannst du einfach git branch --merged aufrufen: $ git branch --merged iss53 * master Da du den Branch iss53 schon gemergt hast, siehst du ihn in dieser Liste. Alle Branches in dieser Liste, welchen kein * voransteht, können ohne Datenverlust mit git branch -d gelöscht werden, da sie ja bereits gemergt wurden. Um alle Branches zu sehen, welche noch nicht gemergte Änderungen enthalten, kannst du git branch --no-merged aufrufen: $ git branch --no-merged testing Die Liste zeigt dir den anderen Branch. Er enthält Arbeit, die noch nicht gemergt wurde. Der Versuch, den Branch mit git branch -d zu löschen schlägt fehl: $ git branch -d testing error: The branch 'testing' is not an ancestor of your current HEAD. If you are sure you want to delete it, run `git branch -D testing`. Wenn du den Branch trotzdem löschen willst - und damit alle Änderungen dieses Branches verlieren - kannst du das mit git branch -D testing machen. 4.5 Branching Workflows Jetzt da du die Grundlagen von branching und merging kennst, fragst du dich sicher, was du damit anfangen kannst. In diesem Abschnitt werden wir uns typische Workflows anschauen, die dieses leichtgewichtige branching möglich machen. Und somit kannst du dann entscheiden, ob du es in deinem eigene Entwicklungszyklus verwenden willst. Now that you have the basics of branching and merging down, what can or should you do with them? In this section, we ll cover some common workflows that this lightweight branching makes possible, so you can decide if you would like to incorporate it into your own development cycle. 84

99 Scott Chacon Pro Git Section 4.5 Branching Workflows Langfristige Branches Long-Running Branches Da Git den einfachen 3-Wege- merge verwendet, ist häufiges Zusammenführen von einem Branch in einen anderen über einen langen Zeitraum generell einfach zu bewerkstelligen. Das heisst, du kann mehrere Branches haben, die alle offen sind und auf unterschiedlichen Ebenen deines Entwicklungszyklus verwendung finden, und diese regelmäßig ineinander zusammenführen. Because Git uses a simple three-way merge, merging from one branch into another multiple times over a long period is generally easy to do. This means you can have several branches that are always open and that you use for different stages of your development cycle; you can merge regularly from some of them into others. Viele Git Entwickler verwenden einen Workflow, der dem Ansatz folgt, nur stabilen Code in dem master Branch zu halten - idealerweise nur Code, der released wurde oder werden kann. Dazu wird parallel ein anderer Branch zum Arbeiten bzw. zum Testen geführt. Wenn dieser einen stabilen Status erreicht, kann er mit dem master Branch zusammengeführt werden. Dies findet bei themenbezogenen Branches (kurzfristige Branches, wie der zuvor erwähnte iss53 Branch) Anwendung, um sicherzustellen, dass diese die Tests bestehen und keine Fehler verursachen. Many Git developers have a workflow that embraces this approach, such as having only code that is entirely stable in their master branch possibly only code that has been or will be released. They have another parallel branch named develop or next that they work from or use to test stability it isn t necessarily always stable, but whenever it gets to a stable state, it can be merged into master. It s used to pull in topic branches (short-lived branches, like your earlier iss53 branch) when they re ready, to make sure they pass all the tests and don t introduce bugs. In Realität reden wir über sich bewegende Pointer, die die Commit Linie weiter wandern. The stabilen Branches liegen unten und die bleeding-edge Branches weiter oben in der Zeitlinie (siehe Abbildung 3-18). In reality, we re talking about pointers moving up the line of commits you re making. The stable branches are farther down the line in your commit history, and the bleeding-edge branches are farther up the history (see Figure 3.18). Figure 4.17: Stabilere Branches sind generell weiter unten im Entwicklungsverlauf. Figure More stable branches are generally farther down the commit history. Es ist leichter sich die verschiedenen Branches als Arbeitsdepots vorzustellen, in denen Sätze von Commits in stabilere Depots aufsteigen, sobald sie ausreichend getestet wurden (siehe Abbildung 3-19). It s generally easier to think about them as work silos, where sets of commits graduate to a more stable silo when they re fully tested (see Figure 3.19). Figure 4.18: Es könnte hilfreich sein, sich die Branches als Depots vorzustellen. Figure It may be helpful to think of your branches as silos. Das lässt sich für beliebig viele Stabilitätsabstufungen umsetzen. Manche größeren Projekte haben auch einen proposed (Vorgeschlagen) oder pu (vorgeschlagene Updates) Zweig mit Branches die vielleicht noch nicht bereit sind in den next- oder master-branch integriert zu werden. Die Idee dahinter ist, dass Branches verschiedene Stabilitätsabstufungen repräsentieren. Sobald sie eine stabilere Stufe erreichen, werden sie in den nächsthöheren Branch vereinigt. Nochmal, langfristig 85

100 Chapter 4 Git Branching Scott Chacon Pro Git verschiedene Branches paralell laufen zu lassen ist nicht notwendig, aber oft hilfreich. Insbesondere wenn man es mit sehr großen oder komplexen Projekten zu tun hat. You can keep doing this for several levels of stability. Some larger projects also have a proposed or pu (proposed updates) branch that has integrated branches that may not be ready to go into the next or master branch. The idea is that your branches are at various levels of stability; when they reach a more stable level, they re merged into the branch above them. Again, having multiple long-running branches isn t necessary, but it s often helpful, especially when you re dealing with very large or complex projects Themen-Branches Topic Branches Themen-Branches sind in jedem Projekt nützlich, egal bei welcher Größe. Ein Themen-Branch ist ein kurzlebiger Zweig der für eine spezielle Aufgabe oder ähnliche Arbeiten erstellt und benutzt wird. Das ist vielleicht etwas was du noch nie zuvor mit einem Versionierungssystem gemacht hast, weil es normalerweise zu aufwändig und mühsam ist Branches zu erstellen und zusammenzuführen. Mit Git ist es allerdings vollkommen geläufig mehrmals am Tag Branches zu erstellen, an ihnen zu arbeiten, sie zusammenzuführen und sie anschließend wieder zu löschen. Topic branches, however, are useful in projects of any size. A topic branch is a short-lived branch that you create and use for a single particular feature or related work. This is something you ve likely never done with a VCS before because it s generally too expensive to create and merge branches. But in Git it s common to create, work on, merge, and delete branches several times a day. Du hast das im letzten Abschnitt an dem von dir erstellten iss53- und hotfix-branches gesehen. Du hast mehrere Commits auf sie angewendet und sie unmittelbar nach Zusammenführung mit deinem Hauptzweig gelöscht. Diese Technik erlaubt es dir schnell und vollständig den Kontext zu wechseln. Da deine Arbeit in verschiedene Depots aufgeteilt ist, in denen alle Änderungen unter die Thematik dieses Branches fallen, ist es leichter nachzuvollziehen was bei Code-Überprüfungen und ähnlichem geschehen ist. You saw this in the last section with the iss53 and hotfix branches you created. You did a few commits on them and deleted them directly after merging them into your main branch. This technique allows you to context-switch quickly and completely because your work is separated into silos where all the changes in that branch have to do with that topic, it s easier to see what has happened during code review and such. You can keep the changes there for minutes, days, or months, and merge them in when they re ready, regardless of the order in which they were created or worked on. Stell dir du arbeitest ein bisschen (in master), erstellst mal eben einen Branch für einen Fehler (iss91), arbeitest an diesem für eine Weile, erstellst einen zweiten Branch um eine andere Problemlösung für den selben Fehler auszuprobieren (iss91v2), wechselst zurück zu deinem MASTER- Branch, arbeitest dort ein bisschen und machst dann einen neuen Branch für etwas, wovon du nicht weißt ob s eine gute Idee ist (dumbidea-branch). Dein Commit-Verlauf wird wie in Abbildung 3-20 aussehen. Consider an example of doing some work (on master), branching off for an issue (iss91), working on it for a bit, branching off the second branch to try another way of handling the same thing (iss91v2), going back to your master branch and working there for a while, and then branching off there to do some work that you re not sure is a good idea (dumbidea branch). Your commit history 86

101 Scott Chacon Pro Git Section 4.6 Externe Branches will look something like Figure Figure 4.19: Dein Commit-Verlauf mit verschiedenen Themen-Branches. Figure Your commit history with multiple topic branches Nun, sagen wir du hast dich entschieden die zweite Lösung des Fehlers (iss91v2) zu bevorzugen, außerdem hast den dumbidea-branch deinen Mitarbeitern gezeigt und es hat sich herausgestellt das er genial ist. Du kannst also den ursprünglichen iss91-branch (unter Verlust der Commits C5 und C6) wegschmeißen und die anderen Beiden vereinen. Dein Verlauf sieht dann aus wie in Abbildung Now, let s say you decide you like the second solution to your issue best (iss91v2); and you showed the dumbidea branch to your coworkers, and it turns out to be genius. You can throw away the original iss91 branch (losing commits C5 and C6) and merge in the other two. Your history then looks like Figure Figure 4.20: Dein Verlauf nach Zusammenführung von dumbidea und iss91v2. Figure Your history after merging in dumbidea and iss91v2 Es ist wichtig sich daran zu erinnern, dass alle diese Branches nur lokal existieren. Wenn du Verzweigungen schaffst (branchst) und wieder zusammenführst (mergest), findet dies nur in deinem Git-Repository statt - es findet keine Server-Kommunikation statt. It s important to remember when you re doing all this that these branches are completely local. When you re branching and merging, everything is being done only in your Git repository no server communication is happening. 4.6 Externe Branches 4.7 Remote Branches Externe Branches sind Referenzen auf den Zustand der Branches in deinen externen Repositorys. Es sind lokale Branches die du nicht verändern kannst, sie werden automatisch verändert wann immer du eine Netzwerkoperation durchführst. Externe Branches verhalten sich wie Lesezeichen, um dich daran zu erinnern an welcher Position sich die Branches in deinen externen Repositories befanden, als du dich zuletzt mit ihnen verbunden hattest. Remote branches are references to the state of branches on your remote repositories. They re local branches that you can t move; they re moved automatically whenever you do any network communication. Remote branches act as bookmarks to remind you where the branches on your remote repositories were the last time you connected to them. Externe Branches besitzen die Schreibweise (Repository)/(Branch). Wenn du beispielsweise wissen möchtest wie der master-branch in deinem origin-repository ausgesehen hat, als du zuletzt Kontakt mit ihm hattest, dann würdest du den origin/master-branch überprüfen. Wenn du mit einem Mitarbeiter an einer Fehlerbehebung gearbeitet hast, und dieser bereits einen iss53-branch hochgeladen hat, besitzt du möglicherweise deinen eigenen lokalen iss53-branch. Der Branch auf dem Server würde allerdings auf den Commit von origin/iss53 zeigen. 87

102 Chapter 4 Git Branching Scott Chacon Pro Git They take the form (remote)/(branch). For instance, if you wanted to see what the master branch on your origin remote looked like as of the last time you communicated with it, you would check the origin/master branch. If you were working on an issue with a partner and they pushed up an iss53 branch, you might have your own local iss53 branch; but the branch on the server would point to the commit at origin/iss53. Das kann ein wenig verwirrend sein, lass uns also ein Besipiel betrachten. Nehmen wir an du hättest in deinem Netzwerk einen Git-Server mit der Adresse Wenn du von ihm klonst, nennt Git ihn automatisch origin für dich, lädt all seine Daten herunter, erstellt einen Zeiger an die Stelle wo sein master-branch ist und benennt es lokal origin/master; und er ist unveränderbar für dich. Git gibt dir auch einen eigenen master-branch mit der gleichen Ausgangsposition wie origins master-branch, damit du einen Punkt für den Beginn deiner Arbeiten hast (siehe Abbildung 3-22). This may be a bit confusing, so let s look at an example. Let s say you have a Git server on your network at If you clone from this, Git automatically names it origin for you, pulls down all its data, creates a pointer to where its master branch is, and names it origin/ master locally; and you can t move it. Git also gives you your own master branch starting at the same place as origin s master branch, so you have something to work from (see Figure 3.22). Figure 4.21: Ein git clone gibt dir deinen eigenen master-branch und origin/master, welcher auf origins master -Branch zeigt. Figure A Git clone gives you your own master branch and origin/master pointing to origin s master branch. Wenn du ein wenig an deinem lokalen master-branch arbeitest und unterdessen jemand etwas zu herauflädt, verändert er damit dessen master-branch und eure Arbeitsverläufe entwickeln sich unterschiedlich. Indess bewegt sich dein origin/master-zeiger nicht, solange du keinen Kontakt mit deinem origin-server aufnimmst (siehe Abbildung 3-23). If you do some work on your local master branch, and, in the meantime, someone else pushes to and updates its master branch, then your histories move forward differently. Also, as long as you stay out of contact with your origin server, your origin/master pointer doesn t move (see Figure 3.23). Figure 4.22: Lokales Arbeiten, während jemand auf deinen externen Server hochlädt, lässt jeden Änderungsverlauf unterschiedlich weiterentwickeln. Figure Working locally and having someone push to your remote server makes each history move forward differently. Um deine Arbeit abzugleichen, führe ein git fetch origin-kommando aus. Das Kommando schlägt nach welcher Server orgin ist (in diesem Fall, holt alle Daten die dir bisher fehlen und aktualisiert deine lokale Datenbank, indem es deinen orgin/ master-zeiger auf seine neue aktuellere Position bewegt (siehe Abbildung 3-24). To synchronize your work, you run a git fetch origin command. This command looks up which server origin is (in this case, it s, fetches any data from it that you don t yet have, and updates your local database, moving your origin/master pointer to its new, more up-to-date position (see Figure 3.24). Figure The git fetch command updates your remote references. 88

103 Scott Chacon Pro Git Section 4.7 Remote Branches Figure 4.23: Das git fetch-kommando aktualisiert deine externen Referenzen. Um zu demonstrieren wie Branches auf verschiedenen Remote-Servern aussehen, stellen wir uns vor, dass du einen weiteren internen Git-Server besitzt, welcher nur von einem deiner Sprint-Teams zur Entwicklung genutzt wird. Diesen Server erreichen wir unter Du kannst ihn, mit dem Git-Kommando git remote add - wie in Kapitel 2 beschrieben, deinem derzeitigen Arbeitsprojekt als weiteren Quell-Server hinzufügen. Gib dem Remote-Server den Namen teamone, welcher nun als Synonym für die ausgeschriebene Internetadresse dient (siehe Abbildung 3-25). To demonstrate having multiple remote servers and what remote branches for those remote projects look like, let s assume you have another internal Git server that is used only for development by one of your sprint teams. This server is at You can add it as a new remote reference to the project you re currently working on by running the git remote add command as we covered in Chapter 2. Name this remote teamone, which will be your shortname for that whole URL (see Figure 3.25). Figure 4.24: Einen weiteren Server als Quelle hinzufügen. Figure Adding another server as a remote Nun kannst du einfach git fetch teamone ausführen um alles vom Server zu holen was du noch nicht hast. Da der Datenbestand auf dem Teamserver einen Teil der Informationen auf deinem origin-server ist, holt Git keine Daten, erstellt allerdings einen Remote-Branch namens teamone/master, der auf den gleichen Commit wie teamones master-branch zeigt (siehe Abbildung 3-26). Now, you can run git fetch teamone to fetch everything server has that you don t have yet. Because that server is a subset of the data your origin server has right now, Git fetches no data but sets a remote branch called teamone/master to point to the commit that teamone has as its master branch (see Figure 3.26). Figure 4.25: Du bekommst eine lokale Referenz auf teamones master-branch. Figure You get a reference to teamone s master branch position locally Hochladen Pushing Wenn du einen Branch mit der Welt teilen möchtest, musst du ihn auf einen externen Server laden, auf dem du Schreibrechte besitzt. Deine lokalen Zweige werden nicht automatisch mit den Remote-Servern synchronisiert wenn du etwas änderst - du musst die zu veröffentlichenden Branches explizit hochladen. Auf diesem Weg kannst du an privaten Zweigen arbeiten die du nicht veröffentlichen möchtest, und nur die Themen-Branches replizieren an denen du gemeinsam mit anderen entwickeln möchtest. When you want to share a branch with the world, you need to push it up to a remote that you have write access to. Your local branches aren t automatically synchronized to the remotes you write to 89

104 Chapter 4 Git Branching Scott Chacon Pro Git you have to explicitly push the branches you want to share. That way, you can use private branches do work you don t want to share, and push up only the topic branches you want to collaborate on. Wenn du einen Zweig namens serverfix besitzt, an dem du mit anderen arbeiten möchtest, dann kannst du diesen auf dieselbe Weise hochladen wie deinen ersten Branch. Führe git push (remote) (branch) aus: If you have a branch named serverfix that you want to work on with others, you can push it up the same way you pushed your first branch. Run git push (remote) (branch): $ git push origin serverfix Counting objects: 20, done. Compressing objects: 100% (14/14), done. Writing objects: 100% (15/15), 1.74 KiB, done. Total 15 (delta 5), reused 0 (delta 0) To * [new branch] serverfix -> serverfix Hierbei handelt es sich um eine Abkürzung. Git erweitert die serverfix-branchbezeichnung automatisch zu refs/heads/serverfix:refs/heads/serverfix, was soviel bedeutet wie Nimm meinen lokalen serverfix-branch und aktualisiere damit den serverfix-branch auf meinem externen Server. Wir werden den refs/heads/-teil in Kapitel 9 noch näher beleuchten, du kannst ihn aber in der Regel weglassen. Du kannst auch git push origin serverfix:serverfix ausführen, was das gleiche bewirkt - es bedeutet Nimm meinen serverfix und mach ihn zum externen serverfix. Du kannst dieses Format auch benutzen um einen lokalen Zweig in einen externen Branch mit anderem Namen zu laden. Wenn du ihn auf dem externen Server nicht serverfix nennen möchtest, könntest du stattdessen git push origin serverfix:awesomebranch ausführen um deinen lokalen serverfix-branch in den awesomebranch-zweig in deinem externen Projekt zu laden. This is a bit of a shortcut. Git automatically expands the serverfix branchname out to refs/ heads/serverfix:refs/heads/serverfix, which means, Take my serverfix local branch and push it to update the remote s serverfix branch. We ll go over the refs/heads/ part in detail in Chapter 9, but you can generally leave it off. You can also do git push origin serverfix:serverfix, which does the same thing it says, Take my serverfix and make it the remote s serverfix. You can use this format to push a local branch into a remote branch that is named differently. If you didn t want it to be called serverfix on the remote, you could instead run git push origin serverfix:awesomebranch to push your local serverfix branch to the awesomebranch branch on the remote project. Das nächste Mal wenn einer deiner Mitarbeiter den aktuellen Status des Git-Projektes vom Server abruft, wird er eine Referenz, auf den externen Branch origin/serverfix, unter dem Namen serverfix erhalten: The next time one of your collaborators fetches from the server, they will get a reference to where the server s version of serverfix is under the remote branch origin/serverfix: $ git fetch origin remote: Counting objects: 20, done. remote: Compressing objects: 100% (14/14), done. 90

105 Scott Chacon Pro Git Section 4.7 Remote Branches remote: Total 15 (delta 5), reused 0 (delta 0) Unpacking objects: 100% (15/15), done. From * [new branch] serverfix -> origin/serverfix Es ist wichtig festzuhalten, dass du mit Abrufen eines neuen externen Branches nicht automatisch eine lokale, bearbeitbare Kopie derselben erhältst. Mit anderen Worten, in diesem Fall bekommst du keinen neuen serverfix-branch - sondern nur einen origin/serverfix-zeiger den du nicht verändern kannst. It s important to note that when you do a fetch that brings down new remote branches, you don t automatically have local, editable copies of them. In other words, in this case, you don t have a new serverfix branch you only have an origin/serverfix pointer that you can t modify. Um diese referenzierte Arbeit mit deinem derzeitigen Arbeitsbranch zusammenzuführen kannst du git merge origin/serverfix ausführen. Wenn du allerdings deine eigene Arbeitskopie des serverfix-branches erstellen möchtest, dann kannst du diesen auf Grundlage des externen Zweiges erstellen: To merge this work into your current working branch, you can run git merge origin/ serverfix. If you want your own serverfix branch that you can work on, you can base it off your remote branch: $ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. Switched to a new branch "serverfix" Zweiges. Dies erstellt dir einen lokalen bearbeitbaren Branch mit der Grundlage des origin/serverfix- This gives you a local branch that you can work on that starts where origin/serverfix is Tracking Branches Checking out a local branch from a remote branch automatically creates what is called a tracking branch. Tracking branches are local branches that have a direct relationship to a remote branch. If you re on a tracking branch and type git push, Git automatically knows which server and branch to push to. Also, running git pull while on one of these branches fetches all the remote references and then automatically merges in the corresponding remote branch. When you clone a repository, it generally automatically creates a master branch that tracks origin/master. That s why git push and git pull work out of the box with no other arguments. However, you can set up other tracking branches if you wish ones that don t track branches on origin and don t track the master branch. The simple case is the example you just saw, running git checkout -b [branch] [remotename]/[branch]. If you have Git version or later, you can also use the --track shorthand: $ git checkout --track origin/serverfix Branch serverfix set up to track remote branch refs/remotes/origin/serverfix. 91

106 Chapter 4 Git Branching Scott Chacon Pro Git Switched to a new branch "serverfix" To set up a local branch with a different name than the remote branch, you can easily use the first version with a different local branch name: $ git checkout -b sf origin/serverfix Branch sf set up to track remote branch refs/remotes/origin/serverfix. Switched to a new branch "sf" Now, your local branch sf will automatically push to and pull from origin/serverfix Deleting Remote Branches Suppose you re done with a remote branch say, you and your collaborators are finished with a feature and have merged it into your remote s master branch (or whatever branch your stable codeline is in). You can delete a remote branch using the rather obtuse syntax git push [remotename] :[branch]. If you want to delete your serverfix branch from the server, you run the following: $ git push origin :serverfix To - [deleted] serverfix Boom. No more branch on your server. You may want to dog-ear this page, because you ll need that command, and you ll likely forget the syntax. A way to remember this command is by recalling the git push [remotename] [localbranch]:[remotebranch] syntax that we went over a bit earlier. If you leave off the [localbranch] portion, then you re basically saying, Take nothing on my side and make it be [remotebranch]. 4.8 Rebasing In Git, there are two main ways to integrate changes from one branch into another: the merge and the rebase. In this section you ll learn what rebasing is, how to do it, why it s a pretty amazing tool, and in what cases you won t want to use it The Basic Rebase If you go back to an earlier example from the Merge section (see Figure 3.27), you can see that you diverged your work and made commits on two different branches. Figure 4.26: Your initial diverged commit history The easiest way to integrate the branches, as we ve already covered, is the merge command. It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most 92

107 Scott Chacon Pro Git Section 4.8 Rebasing recent common ancestor of the two (C2), creating a new snapshot (and commit), as shown in Figure Figure 4.27: Merging a branch to integrate the diverged work history However, there is another way: you can take the patch of the change that was introduced in C3 and reapply it on top of C4. In Git, this is called rebasing. With the rebase command, you can take all the changes that were committed on one branch and replay them on another one. In this example, you d run the following: $ git checkout experiment $ git rebase master First, rewinding head to replay your work on top of it... Applying: added staged command It works by going to the common ancestor of the two branches (the one you re on and the one you re rebasing onto), getting the diff introduced by each commit of the branch you re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn. Figure 3.29 illustrates this process. Figure 4.28: Rebasing the change introduced in C3 onto C4 3.30). At this point, you can go back to the master branch and do a fast-forward merge (see Figure Figure 4.29: Fast-forwarding the master branch Now, the snapshot pointed to by C3 is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel. Often, you ll do this to make sure your commits apply cleanly on a remote branch perhaps in a project to which you re trying to contribute but that you don t maintain. In this case, you d do your work in a branch and then rebase your work onto origin/master when you were ready to submit your patches to the main project. That way, the maintainer doesn t have to do any integration work just a fast-forward or a clean apply. Note that the snapshot pointed to by the final commit you end up with, whether it s the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot it s only the history that is different. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together More Interesting Rebases You can also have your rebase replay on something other than the rebase branch. Take a history like Figure 3.31, for example. You branched a topic branch (server) to add some server-side 93

108 Chapter 4 Git Branching Scott Chacon Pro Git functionality to your project, and made a commit. Then, you branched off that to make the client-side changes (client) and committed a few times. Finally, you went back to your server branch and did a few more commits. Figure 4.30: A history with a topic branch off another topic branch Suppose you decide that you want to merge your client-side changes into your mainline for a release, but you want to hold off on the server-side changes until it s tested further. You can take the changes on client that aren t on server (C8 and C9) and replay them on your master branch by using the --onto option of git rebase: $ git rebase --onto master server client This basically says, Check out the client branch, figure out the patches from the common ancestor of the client and server branches, and then replay them onto master. It s a bit complex; but the result, shown in Figure 3.32, is pretty cool. Figure 4.31: Rebasing a topic branch off another topic branch Now you can fast-forward your master branch (see Figure 3.33): $ git checkout master $ git merge client Figure 4.32: Fast-forwarding your master branch to include the client branch changes Let s say you decide to pull in your server branch as well. You can rebase the server branch onto the master branch without having to check it out first by running git rebase [basebranch] [topicbranch] which checks out the topic branch (in this case, server) for you and replays it onto the base branch (master): $ git rebase master server This replays your server work on top of your master work, as shown in Figure Figure 4.33: Rebasing your server branch on top of your master branch Then, you can fast-forward the base branch (master): $ git checkout master $ git merge server 94

109 Scott Chacon Pro Git Section 4.8 Rebasing You can remove the client and server branches because all the work is integrated and you don t need them anymore, leaving your history for this entire process looking like Figure 3.35: $ git branch -d client $ git branch -d server Figure 4.34: Final commit history The Perils of Rebasing Ahh, but the bliss of rebasing isn t without its drawbacks, which can be summed up in a single line: Do not rebase commits that you have pushed to a public repository. If you follow that guideline, you ll be fine. If you don t, people will hate you, and you ll be scorned by friends and family. When you rebase stuff, you re abandoning existing commits and creating new ones that are similar but different. If you push commits somewhere and others pull them down and base work on them, and then you rewrite those commits with git rebase and push them up again, your collaborators will have to re-merge their work and things will get messy when you try to pull their work back into yours. Let s look at an example of how rebasing work that you ve made public can cause problems. Suppose you clone from a central server and then do some work off that. Your commit history looks like Figure Figure 4.35: Clone a repository, and base some work on it. Now, someone else does more work that includes a merge, and pushes that work to the central server. You fetch them and merge the new remote branch into your work, making your history look something like Figure Figure 4.36: Fetch more commits, and merge them into your work. Next, the person who pushed the merged work decides to go back and rebase their work instead; they do a git push --force to overwrite the history on the server. You then fetch from that server, bringing down the new commits. Figure 4.37: Someone pushes rebased commits, abandoning commits you ve based your work on. At this point, you have to merge this work in again, even though you ve already done so. Rebasing changes the SHA-1 hashes of these commits so to Git they look like new commits, when in fact you already have the C4 work in your history (see Figure 3.39). You have to merge that work in at some point so you can keep up with the other developer in the future. After you do that, your commit history will contain both the C4 and C4 commits, which have 95

110 Chapter 4 Git Branching Scott Chacon Pro Git Figure 4.38: You merge in the same work again into a new merge commit. different SHA-1 hashes but introduce the same work and have the same commit message. If you run a git log when your history looks like this, you ll see two commits that have the same author date and message, which will be confusing. Furthermore, if you push this history back up to the server, you ll reintroduce all those rebased commits to the central server, which can further confuse people. If you treat rebasing as a way to clean up and work with commits before you push them, and if you only rebase commits that have never been available publicly, then you ll be fine. If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble. 4.9 Summary We ve covered basic branching and merging in Git. You should feel comfortable creating and switching to new branches, switching between branches and merging local branches together. You should also be able to share your branches by pushing them to a shared server, working with others on shared branches and rebasing your branches before they are shared. 96

111 Chapter 5 Git on the Server 97


113 Chapter 6 Git auf dem Server At this point, you should be able to do most of the day-to-day tasks for which you ll be using Git. However, in order to do any collaboration in Git, you ll need to have a remote Git repository. Although you can technically push changes to and pull changes from individuals repositories, doing so is discouraged because you can fairly easily confuse what they re working on if you re not careful. Furthermore, you want your collaborators to be able to access the repository even if your computer is offline having a more reliable common repository is often useful. Therefore, the preferred method for collaborating with someone is to set up an intermediate repository that you both have access to, and push to and pull from that. We ll refer to this repository as a Git server ; but you ll notice that it generally takes a tiny amount of resources to host a Git repository, so you ll rarely need to use an entire server for it. Zum jetzigen Zeitpunkt solltest du in der Lage sein, die am häufigsten wiederkehrenden Aufgaben mit Git zu lösen. Um Zusammenarbeit zu ermöglichen solltest du jedoch darüber nachdenken, ein externes Repository zur Verfügung stellen. Wenngleich es technisch ohne Weiteres möglich ist, direkt mit Repositories Anderer zu arbeiten und Änderungen dorthin zu pushen oder von dort zu holen, macht es dieses Vorgehen zu leicht Verwirrung zu stiften. Wenn man nicht vorsichtig ist, verliert man schnell den Überblick darüber wer woran arbeitet. Des weiteren erfordert der direkte Umgang mit Git Repositories, dass diese permanent verfügbar sind. Ein Repository auf dem eigenen Computer ist nur dann für alle Mitentwickler erreichbar, wenn der Computer läuft. Es macht deshalb Sinn, ein zentrales und zuverlässig erreichbares Repository einzurichten. Wir werden dieses Repository im Folgenden als Git Server bezeichnen. Es sollte jedoch schnell klar werden, dass nur minimale Ressourcen notwendig sind, um Git Repositories zu hosten. In den seltensten Fällen ist ein dedizierter Server dafür notwendig. Running a Git server is simple. First, you choose which protocols you want your server to communicate with. The first section of this chapter will cover the available protocols and the pros and cons of each. The next sections will explain some typical setups using those protocols and how to get your server running with them. Last, we ll go over a few hosted options, if you don t mind hosting your code on someone else s server and don t want to go through the hassle of setting up and maintaining your own server. Einen Git Server zu betreiben ist einfach. Die erste Entscheidung, die zu treffen ist, ist die des zu verwendenden Protokolls zur Kommunikation mit dem Server. Der erste Teil dieses Kapitels wird deshalb die zur Verfügung stehenden Protokolle und ihre Vor und Nachteile beschreiben. Darüber hinaus werden einige typische Konfigurationen zum Betreiben eines Git Servers vorgestellt. Für den Fall, dass keine Bedenken bestehen, Code von externen Anbietern hosten zu lassen, werden zuletzt 99

114 Chapter 6 Git auf dem Server Scott Chacon Pro Git ein paar Optionen für gehostete Git Repositories gezeigt. Dies erspart die Mehrarbeit der Einrichtung und Wartung eines eigenen Git Servers. If you have no interest in running your own server, you can skip to the last section of the chapter to see some options for setting up a hosted account and then move on to the next chapter, where we discuss the various ins and outs of working in a distributed source control environment. Wenn du kein Interesse am Betreiben eines eigenen Servers hast, kannst du zum letzten Absatz des Kapitels springen, um ein paar Möglichkeiten zum Einrichten eines gehosteten Accounts zu sehen. Im nächsten Kapitel diskutieren wir verschiedene Vorteile und Nachteile vom Arbeiten in einer verteilten Quellcode-Kontroll-Umgebung. A remote repository is generally a bare repository a Git repository that has no working directory. Because the repository is only used as a collaboration point, there is no reason to have a snapshot checked out on disk; it s just the Git data. In the simplest terms, a bare repository is the contents of your project s.git directory and nothing else. Ein externes Repository ist im Allgemeinen ein einfaches Repository - ein Git Repository ohne Arbeitsverzeichnis. Weil das Repository nur als Zusammenarbeitspunkt genutzt wird, gibt es keinen Grund, einen Schnappschuss ausgecheckt auf der Festplatte zu haben; es sind nur die Git Daten. Mit einfachen Begriffen, ein einfaches Repository ist der Inhalt von deinem.git Verzeichnis in deinem Projekt und nichts anderes. 6.1 The Protocols 6.2 Die Protokolle Git can use four major network protocols to transfer data: Local, Secure Shell (SSH), Git, and HTTP. Here we ll discuss what they are and in what basic circumstances you would want (or not want) to use them. Git kann vier wichtige Netzwerk Protokolle zum Datentransfer benutzen: Lokal, Secure Shell (SSH), Git und HTTP. Hier wollen wir diskutieren, was diese Protokolle sind und unter welchen grundlegenden Gegebenheiten du sie benutzen möchtest (oder auch nicht). It s important to note that with the exception of the HTTP protocols, all of these require Git to be installed and working on the server. Es ist wichtig zu beachten, dass alle Protokolle mit Ausnahme von HTTP eine funktionierende Git Installation auf dem Server benötigen Local Protocol Lokales Protokoll The most basic is the Local protocol, in which the remote repository is in another directory on disk. This is often used if everyone on your team has access to a shared filesystem such as an NFS mount, or in the less likely case that everyone logs in to the same computer. The latter wouldn t be ideal, because all your code repository instances would reside on the same computer, making a catastrophic loss much more likely. Am einfachsten ist das Lokale Protokoll, wobei das externe Repository in einem anderen Verzeichnis auf der Festplatte ist. Das wird oft genutzt, wenn jeder aus deinem Team Zugriff zu einem gemeinsamen Dateisystem hat, zum Beispiel ein eingebundenes NFS, oder im unwahrscheinlicheren 100

115 Scott Chacon Pro Git Section 6.2 Die Protokolle Fall jeder loggt sich auf bei dem gleichen Computer ein. Das letztere ist nicht ideal, weil alle Code Repository Instanzen auf dem selben Computer wären, ein katastrophaler Verlust wäre wahrscheinlicher. If you have a shared mounted filesystem, then you can clone, push to, and pull from a local filebased repository. To clone a repository like this or to add one as a remote to an existing project, use the path to the repository as the URL. For example, to clone a local repository, you can run something like this: Wenn du ein gemeinsames Dateisystem eingebunden hast, kannst du von einem lokalen Dateibasiertem Repository clonen, pushen und pullen. Um ein Repository wie dieses zu clonen, oder ein externes zu einem bestehenden Projekt hinzuzufügen, benutze den Pfad zu dem Repository als URL. Um zum Beispiel ein lokales Repository zu clonen kannst du einen Befehl wie diesen nutzen: $ git clone /opt/git/project.git Or you can do this: Oder du kannst das machen: $ git clone file:///opt/git/project.git Git operates slightly differently if you explicitly specify file:// at the beginning of the URL. If you just specify the path, Git tries to use hardlinks or directly copy the files it needs. If you specify file://, Git fires up the processes that it normally uses to transfer data over a network which is generally a lot less efficient method of transferring the data. The main reason to specify the file:// prefix is if you want a clean copy of the repository with extraneous references or objects left out generally after an import from another version-control system or something similar (see Chapter 9 for maintenance tasks). We ll use the normal path here because doing so is almost always faster. Git arbeitet etwas anders, wenn du am Anfang der URL ausdrücklich file:// angibst. Wenn du nur den Pfad angibst, versucht Git harte Links zu benutzen oder Git kopiert direkt die benötigten Dateien. Wenn du file:// angibst, startet Git den Prozess, den es normalerweise zum Übertragen von Daten über ein Netzwerk verwendet, dass ist gewöhnlich eine wesentlich ineffizientere Methode zum Übertragen der Daten. Der Hauptgrund das file://-präfix anzugeben ist eine saubere Kopie von dem Repository mit fremden Referenzen oder fehlenden Objekten - generell nach einem Import von einem anderen Versionskontrollsystem oder etwas ähnliches (siehe Kapitel 9 für Wartungsarbeiten). Wir benutzen hier den normalen Pfad, weil das fast immer schneller ist. To add a local repository to an existing Git project, you can run something like this: Um ein lokales Repository zu einem existierenden Git Projekt hinzuzufügen, kannst du einen Befehl wie diesen ausführen: $ git remote add local_proj /opt/git/project.git Then, you can push to and pull from that remote as though you were doing so over a network. Dann kannst du von einem externen Repository pushen und pullen, obwohl du das über ein Netzwerk machst. 101

116 Chapter 6 Git auf dem Server Scott Chacon Pro Git The Pros SUBSUBSECTION: Die Vorteile The pros of file-based repositories are that they re simple and they use existing file permissions and network access. If you already have a shared filesystem to which your whole team has access, setting up a repository is very easy. You stick the bare repository copy somewhere everyone has shared access to and set the read/write permissions as you would for any other shared directory. We ll discuss how to export a bare repository copy for this purpose in the next section, Getting Git on a Server. Die Vorteile von Datei-basierten Repositories sind die Einfachheit und sie nutzen bestehende Datei-Berechtigungen und den bestehenden Netzwerk-Zugriff. Wenn du bereits ein gemeinsames Dateisystem hast, zu dem das gesamte Team Zugriff hat, ist das Einrichten eines Repositories sehr einfach. Du extrahierst die Kopie des einfachen Repositories dahin, wo jeder gemeinsamen Zugriff hat und stellst die Lese- und Schreibberechtigungen wie bei jedem anderem gemeinsamen Verzeichnis ein. Wir werden im nächsten Abschnitt Git auf einen Server bekommen. diskutieren, wie man die Kopie eines einfachen Repositories für diesen Zweck exportiert. This is also a nice option for quickly grabbing work from someone else s working repository. If you and a co-worker are working on the same project and they want you to check something out, running a command like git pull /home/john/project is often easier than them pushing to a remote server and you pulling down. Dies ist auch eine nette Möglichkeit zum Schnellen besorgen von Arbeit aus dem Arbeitsverzeichnis von jemand anderem. Wenn du und ein Kollege an dem gleichen Projekt arbeitet und ihr wollt etwas auschecken, ein Befehl wie git pull /home/john/project ist oft einfacher als das pushen zu einem externen Server und das pullen zurück. The Cons SUBSUBSECTION: Die Nachteile The cons of this method are that shared access is generally more difficult to set up and reach from multiple locations than basic network access. If you want to push from your laptop when you re at home, you have to mount the remote disk, which can be difficult and slow compared to network-based access. Die Nachteile von dieser Methode sind, dass gemeinsamer Zugriff im Allgemeinen schwieriger einrichten ist und der Zugriff von mehreren Orten ist schwieriger als einfacher Netzwerk Zugriff. Wenn du von deinem Laptop zuhause pushen möchtest, musst du eine entfernte Festplatte einbinden. Das kann schwierig und langsam sein, verglichen mit Netzwerk-basiertem Zugriff. It s also important to mention that this isn t necessarily the fastest option if you re using a shared mount of some kind. A local repository is fast only if you have fast access to the data. A repository on NFS is often slower than the repository over SSH on the same server, allowing Git to run off local disks on each system. Es ist auch wichtig zu erwähnen, dass dies nicht unbedingt die schnellste Möglichkeit ist, wenn du ein gemeinsames Dateisystem oder ähnliches hast. Ein lokales Repository ist nur dann schnell, wenn du schnellen Zugriff auf die Daten hast. Ein NFS-basiertes Repository ist oftmals langsamer als ein Repository über SSH auf dem gleichen Server, weil Git über SSH auf jedem System auf den lokalen Festplatten arbeitet. 102

117 Scott Chacon Pro Git Section 6.2 Die Protokolle The SSH Protocol Das SSH Protokoll Probably the most common transport protocol for Git is SSH. This is because SSH access to servers is already set up in most places and if it isn t, it s easy to do. SSH is also the only networkbased protocol that you can easily read from and write to. The other two network protocols (HTTP and Git) are generally read-only, so even if you have them available for the unwashed masses, you still need SSH for your own write commands. SSH is also an authenticated network protocol; and because it s ubiquitous, it s generally easy to set up and use. Das vermutlich gebräuchlichste Transport-Protokoll für Git ist SSH. Das hat den Grund, weil der SSH-Zugriff an den meisten Orten bereits eingerichtet ist - und wenn das nicht der Fall ist, ist es einfach zu machen. SSH ist außerdem das einzige Netzwerk-basierte Protokoll von dem man einfach lesen und darauf schreiben kann. Die beiden anderen Netzwerk-Protokolle (HTTP und Git) sind nur lesbar. Auch wenn sie für die breite Masse sind, brauchst du trotzdem SSH für deine Schreib- Befehle. SSH ist auch ein authentifiziertes Netzwerk-Protokoll, und weil es universell ist, ist es im Allgemeinen einfach einzurichten und zu benutzen. To clone a Git repository over SSH, you can specify ssh:// URL like this: Um ein Git Repository über SSH zu clonen, kannst du eine ssh:// URL angeben: $ git clone Or you can not specify a protocol Git assumes SSH if you aren t explicit: Oder du kannst auch kein Protokoll angeben - Git nimmt SSH an, wenn du nicht eindeutig bist: $ git clone You can also not specify a user, and Git assumes the user you re currently logged in as. Du kannst auch keinen Benutzer angeben, und Git nimmt den Benutzer an, als der du gerade eingeloggt bist. The Pros Die Vorteile The pros of using SSH are many. First, you basically have to use it if you want authenticated write access to your repository over a network. Second, SSH is relatively easy to set up SSH daemons are commonplace, many network admins have experience with them, and many OS distributions are set up with them or have tools to manage them. Next, access over SSH is secure all data transfer is encrypted and authenticated. Last, like the Git and Local protocols, SSH is efficient, making the data as compact as possible before transferring it. Die Vorteile von SSH sind vielseitig. Erstens, grundlegend musst du es benutzen, wenn du authentifizierten Schreib-Zugriff auf dein Repository über ein Netzwerk haben möchtest. Zweitens, SSH ist relativ einfach einzurichten - SSH-Dämonen sind alltäglich, viele Netzwerk-Administratoren haben Erfahrungen mit ihnen und viele Betriebssysteme sind mit ihnen eingerichtet oder haben Tools 103

118 Chapter 6 Git auf dem Server Scott Chacon Pro Git um sie zu verwalten. Als nächstes, Zugriff über SSH ist sicher - der gesamte Daten-Transfer ist verschlüsselt und authentifiziert. Als letztes, wie Git und die Lokalen Protokolle, SSH ist effizient, es macht die Daten so kompakt wie möglich bevor es die Daten überträgt. The Cons Die Nachteile The negative aspect of SSH is that you can t serve anonymous access of your repository over it. People must have access to your machine over SSH to access it, even in a read-only capacity, which doesn t make SSH access conducive to open source projects. If you re using it only within your corporate network, SSH may be the only protocol you need to deal with. If you want to allow anonymous read-only access to your projects, you ll have to set up SSH for you to push over but something else for others to pull over. Die negative Seite von SSH ist, dass du deine Repositories nicht anonym darüber anbieten kannst. Die Leute müssen Zugriff auf deine Maschine über SSH haben um zuzugreifen, auch mit einem Nur-Lese-Zugriff, was SSH nicht zuträglich zu Open-Source-Projekten macht. Wenn du es nur innerhalb von deinem Firmen-Netzwerk benutzt, SSH ist vielleicht das einzige Protokoll mit dem du arbeiten musst. Wenn du anonymen Nur-Lese-Zugriff zu deinen Projekten erlauben willst, musst du SSH für dich einsetzen um zu pushen, aber ein anderes Protokoll für andere um zu pullen The Git Protocol Das Git Protokoll Next is the Git protocol. This is a special daemon that comes packaged with Git; it listens on a dedicated port (9418) that provides a service similar to the SSH protocol, but with absolutely no authentication. In order for a repository to be served over the Git protocol, you must create the gitexport-daemon-ok file the daemon won t serve a repository without that file in it but other than that there is no security. Either the Git repository is available for everyone to clone or it isn t. This means that there is generally no pushing over this protocol. You can enable push access; but given the lack of authentication, if you turn on push access, anyone on the internet who finds your project s URL could push to your project. Suffice it to say that this is rare. Als nächstes kommt das Git Protokoll. Das ist ein spezieller Dämon, der zusammen mit Git kommt. Er horcht auf einem bestimmten Port (9418), dieser Service ist vergleichbar mit dem SSH- Protokoll, aber ohne jegliche Authentifizierung. Um ein Repository über das Git Protokoll, musst du die gitk-export-daemon-ok Datei erstellen - der Dämon bietet kein Repository ohne die Datei darin an - außer dieser Datei gibt es keine Sicherheit. Entweder das Git Repository ist für jeden zum Clonen verfügbar oder halt nicht. Das bedeutet, dass dieses Protokoll generell kein push anbietet. Du kannst push-zugriff aktivieren; aber ohne Authentifizierung, wenn du den push-zugriff aktivierst, kann jeder im Internet, der deine Projekt-URL findet, zu deinem Projekt pushen. Ausreichend zu sagen, dass das selten ist. The Pros Die Vorteile The Git protocol is the fastest transfer protocol available. If you re serving a lot of traffic for a public project or serving a very large project that doesn t require user authentication for read access, 104

119 Scott Chacon Pro Git Section 6.2 Die Protokolle it s likely that you ll want to set up a Git daemon to serve your project. It uses the same data-transfer mechanism as the SSH protocol but without the encryption and authentication overhead. Das Git Protokoll ist das schnellste verfügbare Transfer Protokoll. Wenn du viel Traffic für ein öffentliches Projekt hast oder ein sehr großes Projekt hast, dass keine Benutzer-Authentifizierung für den Lese-Zugriff voraussetzt, es ist üblich einen Git Dämon einzurichten, der dein Projekt serviert. Er benutzt den selben Daten-Transfer Mechanismus wie das SSH-Protokoll, aber ohne den Entschlüsselungsund Authentifizierungs-Overhead. The Cons Die Nachteile The downside of the Git protocol is the lack of authentication. It s generally undesirable for the Git protocol to be the only access to your project. Generally, you ll pair it with SSH access for the few developers who have push (write) access and have everyone else use git:// for read-only access. It s also probably the most difficult protocol to set up. It must run its own daemon, which is custom we ll look at setting one up in the Gitosis section of this chapter it requires xinetd configuration or the like, which isn t always a walk in the park. It also requires firewall access to port 9418, which isn t a standard port that corporate firewalls always allow. Behind big corporate firewalls, this obscure port is commonly blocked. Die Unterseite von dem Git Protokoll ist das fehlen der Authentifizierung. Es ist generell unerwünscht, dass das Git Protokoll der einzige Zugang zu dem Projekt ist. Im Allgemeinen willst du es mit SSH-Zugriff für die Entwickler paaren, die push (Schreib) Zugriff haben und jeder andere benutzt git:// für Nur-Lese-Zugriff. Es ist vielleicht auch das das schwierigste Protokoll beim Einrichten. Es muss ein eigener Dämon laufen, welcher Git-spezifisch ist - wir wollen im Gitosis -Abschnitt in diesem Kapitel schauen, wie man einen einrichtet - es setzt eine xinetd-konfiguration oder ähnliches voraus, das ist nicht immer wie ein Spaziergang im Park. Es setzt auch einen Firewall-Zugriff auf den Port 9418 voraus, das ist kein Standard-Port, den Firmen-Firewalls immer erlauben. Hinter einer großen Firmen-Firewall ist dieser unklare Port häufig gesperrt The HTTP/S Protocol Das HTTP/S Protokoll Last we have the HTTP protocol. The beauty of the HTTP or HTTPS protocol is the simplicity of setting it up. Basically, all you have to do is put the bare Git repository under your HTTP document root and set up a specific post-update hook, and you re done (See Chapter 7 for details on Git hooks). At that point, anyone who can access the web server under which you put the repository can also clone your repository. To allow read access to your repository over HTTP, do something like this: Als letztes haben wir das HTTP Protokoll. Das Schöne am HTTP bzw. HTTPS Protokoll ist die Einfachheit des Einrichtens. Im Grunde musst du nur das einfach Git Repository in dein HTTP Hauptverzeichnis legen und einen speziellen post-update hook (xxx) einrichten und schon bist du fertig (siehe Kapitel 7 für Details zu Git hooks (xxx)). Jetzt kann jeder, der auf den Web-Server mit dem Repository zugreifen kann, das Repository clonen. Um Lese-Zugriff auf das Repository über HTTP zu erlauben, führe die folgenden Befehle aus: 105

120 Chapter 6 Git auf dem Server Scott Chacon Pro Git $ cd /var/www/htdocs/ $ git clone --bare /path/to/git_project gitproject.git $ cd gitproject.git $ mv hooks/post-update.sample hooks/post-update $ chmod a+x hooks/post-update That s all. The post-update hook that comes with Git by default runs the appropriate command (git update-server-info) to make HTTP fetching and cloning work properly. This command is run when you push to this repository over SSH; then, other people can clone via something like Das ist alles. Der post-update hook (xxx) der Standardmäßig zusammen mit Git kommt führt den richtigen Befehl aus (git update-server-info), damit der HTTP-Server das Repository richtig abruft und klont. Dieser Befehl läuft, wenn du zu diesem Repository per SSH pusht, andere Leute können dann clonen mit dem Befehl $ git clone In this particular case, we re using the /var/www/htdocs path that is common for Apache setups, but you can use any static web server just put the bare repository in its path. The Git data is served as basic static files (see Chapter 9 for details about exactly how it s served). In diesem besonderen Fall benutzen dir den /var/www/htdocs-pfad, der typisch für Apache- Setups ist, aber du kannst jeden statischen Web-Server benutzen - nur das einfache Repository in den richtigen Ordner legen. Die Git-Daten werden als einfache statische Dateien serviert (siehe Kapitel 9 für Details, wie es genau serviert wird). It s possible to make Git push over HTTP as well, although that technique isn t as widely used and requires you to set up complex WebDAV requirements. Because it s rarely used, we won t cover it in this book. If you re interested in using the HTTP-push protocols, you can read about preparing a repository for this purpose at docs/howto/setup-git-server-over-http.txt. One nice thing about making Git push over HTTP is that you can use any WebDAV server, without specific Git features; so, you can use this functionality if your web-hosting provider supports WebDAV for writing updates to your web site. Es ist möglich, Git-Daten auch über HTTP zu pushen, trotzdem wird diese Technik nicht oft eingesetzt und es setzt komplexe WebDAV-Anforderungen voraus. Weil es selten genutzt wird, werden wir das nicht in diesem Buch behandeln. Wenn du Interesse am HTTP-Push-Protokoll hast, kannst du das Einrichten unter setup-git-server-over-http.txt nachlesen. Eine Schöne Sache über Git-Push über HTTP ist, dass du jeden WebDAV-Server benutzen kannst, ohne spezifische Git-Features; also kannst du diese Funktionalität nutzen, wenn dein Web-Hosting-Provider WebDAV unterstützt, um Änderungen auf deine Webseite zu schreiben. 106

121 Scott Chacon Pro Git Section 6.2 Die Protokolle The Pros Die Vorteile The upside of using the HTTP protocol is that it s easy to set up. Running the handful of required commands gives you a simple way to give the world read access to your Git repository. It takes only a few minutes to do. The HTTP protocol also isn t very resource intensive on your server. Because it generally uses a static HTTP server to serve all the data, a normal Apache server can serve thousands of files per second on average it s difficult to overload even a small server. Die Oberseite beim Benutzen des HTTP-Protokolls ist, dass es einfach einzurichten ist. Das Ausführen von einer Handvoll notwendiger Befehle ist ein einfacher Weg, um der Welt Lese-Zugriff auf dein Git-Repository zu geben. Es braucht nur ein paar Minuten. Das HTTP Protokoll braucht auch nicht viele Ressourcen auf deinem Server. Es braucht generell nur einen statischen Server braucht um die Daten zu servieren. Ein normaler Apache-Server kann Tausende von Dateien pro Sekunde servieren - es ist schwierig selbst einen kleinen Server zu überlasten. You can also serve your repositories read-only over HTTPS, which means you can encrypt the content transfer; or you can go so far as to make the clients use specific signed SSL certificates. Generally, if you re going to these lengths, it s easier to use SSH public keys; but it may be a better solution in your specific case to use signed SSL certificates or other HTTP-based authentication methods for read-only access over HTTPS. Du kannst deine Repositories auch als Nur-Lese-Repositories über HTTPS servieren, du kannst also den Daten-Transfer verschlüsseln. Oder du kannst so weit gehen, dass die Clients spezifische signierte SSL-Zertifikate benutzen. Im Allgemeinen, wenn du soweit gehst, ist es einfacher, öffentliche SSH-Schlüssel zu benutzen; aber es ist vielleicht für deinen Fall eine bessere Lösung, signierte SSL-Zertifikate zu benutzen oder andere HTTP-basierte Authentifizierungs-Methoden für Nur-Lese-Zugriff über HTTPS zu benutzen. Another nice thing is that HTTP is such a commonly used protocol that corporate firewalls are often set up to allow traffic through this port. Eine andere schöne Sache ist, dass HTTP so oft genutzt wird, dass Firmen-Firewalls oft Traffic über den HTTP-Port erlauben. The Cons Die Nachteile The downside of serving your repository over HTTP is that it s relatively inefficient for the client. It generally takes a lot longer to clone or fetch from the repository, and you often have a lot more network overhead and transfer volume over HTTP than with any of the other network protocols. Because it s not as intelligent about transferring only the data you need there is no dynamic work on the part of the server in these transactions the HTTP protocol is often referred to as a dumb protocol. For more information about the differences in efficiency between the HTTP protocol and the other protocols, see Chapter 9. Die Unterseite vom Servieren von deinem Repository über HTTP ist, dass es recht ineffizient für den Client ist. Es braucht im Allgemeinen länger zu clonen oder Daten vom Repository zu holen und du hast oft wesentlich mehr Netzwerk-Overhead und Transfer-Volumen als mit jedem anderen Netzwerk Protokoll. Weil es nicht so intelligent beim Daten-Transfer ist, um nur die benötigten Daten zu übertragen - es gibt keine dynamische Arbeit auf dem Server bei diesen Aktionen - das HTTP 107

122 Chapter 6 Git auf dem Server Scott Chacon Pro Git Protokoll wird oft als dummes Protokoll bezeichnet. Für mehr Informationen über die Unterschiede bei der Effizienz zwischen dem HTTP Protokoll und den anderen Protokollen: siehe Kapitel Getting Git on a Server 6.4 Git auf einen Server bekommen In order to initially set up any Git server, you have to export an existing repository into a new bare repository a repository that doesn t contain a working directory. This is generally straightforward to do. In order to clone your repository to create a new bare repository, you run the clone command with the --bare option. By convention, bare repository directories end in.git, like so: Um zunächst einen beliebigen Git Server einzurichten, musst du ein existierendes Repository in ein neues einfaches Repository exportieren - ein Repository, dass kein Arbeitsverzeichnis enthält. Das ist im Allgemeinen einfach zu erledigen. Um zunächst dein Repository zu klonen, um ein neues einfaches Repository anzulegen, führst du den Klonen-Befehl mit der --bare Option aus. Per Konvention haben einfache Repository Verzeichnisse die Endung.git, wie hier: $ git clone --bare my_project my_project.git Initialized empty Git repository in /opt/projects/my_project.git/ The output for this command is a little confusing. Since clone is basically a git init then a git fetch, we see some output from the git init part, which creates an empty directory. The actual object transfer gives no output, but it does happen. You should now have a copy of the Git directory data in your my_project.git directory. Die Ausgabe für diesen Befehl ist etwas verwirrend. Weil clone im Grunde ein git init und ein git fetch ist, sehen wir eine Ausgabe vom git init-teil, der ein leeres Verzeichnis anlegt. Die eigentliche Objekt-Übertragung erzeugt keine Ausgabe, aber sie findet statt. Du solltest jetzt eine Kopie von den Git-Verzeichnis Daten in deinem my_project.git Verzeichnis haben. This is roughly equivalent to something like Dies ist entsprechend zu etwas wie $ cp -Rf my_project/.git my_project.git There are a couple of minor differences in the configuration file; but for your purpose, this is close to the same thing. It takes the Git repository by itself, without a working directory, and creates a directory specifically for it alone. Es gibt ein paar kleine Unterschiede in der Konfigurationsdatei, aber für deine Zwecke ist es nahezu dasselbe. Es nimmt das Git-Repository von selbst, ohne einem Arbeitsverzeichnis, und erzeugt ein Verzeichnis speziell für sich allein. 108

123 Scott Chacon Pro Git Section 6.4 Git auf einen Server bekommen Putting the Bare Repository on a Server Inbetriebnahme des einfachen Repository auf einem Server Now that you have a bare copy of your repository, all you need to do is put it on a server and set up your protocols. Let s say you ve set up a server called that you have SSH access to, and you want to store all your Git repositories under the /opt/git directory. You can set up your new repository by copying your bare repository over: Da du jetzt eine einfache Kopie deines Repository hast, ist alles was du tun musst das Aufsetzen auf einem Server und das Einrichten deiner Protokolle. Angenommen, du hast einen Server mit dem Namen, zu dem du SSH-Zugang hast, und du möchtest alle deine Git Repositories im Verzeichnis /opt/git speichern. Du kannst dein neues Repository einrichten, indem du dein einfaches Repository dorthin kopierst: $ scp -r my_project.git At this point, other users who have SSH access to the same server which has read-access to the /opt/git directory can clone your repository by running An diesem Punkt können andere Benutzer, die SSH-Zugang zu dem gleichen Server und Lesezugriff auf das /opt/git Verzeichnis haben, dein Repository klonen: $ git clone If a user SSHs into a server and has write access to the /opt/git/my_project.git directory, they will also automatically have push access. Git will automatically add group write permissions to a repository properly if you run the git init command with the --shared option. Wenn sich ein Benutzer per SSH mit dem Server verbindet und Schreibzugriff zu dem Verzeichnis /opt/git/my_project.git hat, wird er automatisch auch Push-Zugriff haben. Git wird automatisch die richtigen Gruppenschreibrechte zu einem Repository hinzufügen, wenn du den git init Befehl mit der --shared Option ausführst: $ ssh $ cd /opt/git/my_project.git $ git init --bare --shared You see how easy it is to take a Git repository, create a bare version, and place it on a server to which you and your collaborators have SSH access. Now you re ready to collaborate on the same project. Du siehst wie einfach es ist ein Git Repository zu nehmen, eine einfache Version zu erzeugen, es auf einen Server zu platzieren zu dem du und deine Mitarbeiter SSH-Zugriff haben. It s important to note that this is literally all you need to do to run a useful Git server to which several people have access just add SSH-able accounts on a server, and stick a bare repository somewhere that all those users have read and write access to. You re ready to go nothing else needed. 109

124 Chapter 6 Git auf dem Server Scott Chacon Pro Git Es ist wichtig zu beachten, dass dies wortwörtlich alles ist, was du tun musst, um einen nützlichen Git-Server laufen zu lassen, zu dem mehrere Personen Zugriff haben - füge auf dem Server einfach SSH-fähige Konten und irgendwo ein einfaches Repository hinzu, zu dem alle Benutzer Schreib- und Lesezugriff haben. In the next few sections, you ll see how to expand to more sophisticated setups. This discussion will include not having to create user accounts for each user, adding public read access to repositories, setting up web UIs, using the Gitosis tool, and more. However, keep in mind that to collaborate with a couple of people on a private project, all you need is an SSH server and a bare repository. In den nächsten Abschnitten wirst du sehen, wie man auf anspruchsvollere Konfigurationen erweitert. Diese Diskussion wird beinhalten nicht Benutzerkonten für jeden Benutzer hinzufügen zu müssen, öffentlichen Lese-Zugriff auf Repositories hinzuzufügen, die Einrichtung von Web-UIs, die Benutzung des Gitosis-Tools und weiteres. Aber denke daran, zur Zusammenarbeit mit ein paar Personen an einem privaten Projekt, ist alles was du brauchst ein SSH-Server und ein einfaches Repository Small Setups Kleine Konfigurationen If you re a small outfit or are just trying out Git in your organization and have only a few developers, things can be simple for you. One of the most complicated aspects of setting up a Git server is user management. If you want some repositories to be read-only to certain users and read/write to others, access and permissions can be a bit difficult to arrange. Wenn du eine kleine Ausrüstung hast oder Git gerade in deinem Unternehmen ausprobierst und nur ein paar Entwickler hast, sind die Dinge einfach für dich. Einer der kompliziertesten Aspekte der Einrichtung eines Git-Servers ist die Benutzerverwaltung. Wenn einige Repositories für bestimmte Benutzer nur lesend zugänglich sein sollen und andere Benutzer Lese/Schreib-Zugriff haben sollen, können Zugriff und Berechtigungen ein bisschen schwierig zu organisieren sein. SSH Access SSH-Zugriff If you already have a server to which all your developers have SSH access, it s generally easiest to set up your first repository there, because you have to do almost no work (as we covered in the last section). If you want more complex access control type permissions on your repositories, you can handle them with the normal filesystem permissions of the operating system your server runs. Wenn du bereits einen Server hast, zu dem alle Entwickler SSH-Zugriff haben, ist es generell einfach, dein erstes Repository einzurichten, weil du fast keine Arbeit zu erledigen hast (wie wir im letzen Abschnitt abgedeckt haben). Wenn du komplexere Zugriffskontroll-Berechtigungen auf deine Repositories willst, kannst du diese mit normalen Dateisystem-Berechtigungen des Betriebssystems deines Servers bewältigen. If you want to place your repositories on a server that doesn t have accounts for everyone on your team whom you want to have write access, then you must set up SSH access for them. We assume that if you have a server with which to do this, you already have an SSH server installed, and that s how you re accessing the server. Wenn du deine Repositories auf einem Server platzieren möchtest, der keine Accounts für jeden 110

125 Scott Chacon Pro Git Section 6.5 Generating Your SSH Public Key aus deinem Team hat, der Schreibzugriff haben soll, dann musst du SSH-Zugriff für diese Personen einrichten. Wir nehmen an, wenn du einen Server hast, mit welchem du dies tun möchtest, du bereits einen SSH-Server installiert hast und so greifst du auf den Server zu. There are a few ways you can give access to everyone on your team. The first is to set up accounts for everybody, which is straightforward but can be cumbersome. You may not want to run adduser and set temporary passwords for every user. Es gibt ein paar Wege allen Mitgliedern deines Teams Zugriff zu geben. Der erste ist einen Account für jeden einzurichten, was unkompliziert aber mühsam sein kann. Du möchtest vielleicht nicht für jeden Benutzer adduser ausführen und ein temporäres Passwort setzen. A second method is to create a single git user on the machine, ask every user who is to have write access to send you an SSH public key, and add that key to the ~/.ssh/authorized_keys file of your new git user. At that point, everyone will be able to access that machine via the git user. This doesn t affect the commit data in any way the SSH user you connect as doesn t affect the commits you ve recorded. Eine zweite Methode ist, einen einzigen git -Benutzer auf der Maschine zu erstellen und jeden Benutzer, der Schreibzugriff haben soll, nach einem öffentliche SSH-Schlüssel zu fragen und diesen Schlüssel zu der ~/.ssh/authorized_keys-datei deines neuen git Benutzers hinzuzufügen. Das beeinflusst die Commit-Daten in keiner Weise - der SSH-Benutzer, mit dem du dich verbindest, beeinflusst die von dir aufgezeichneten Commits nicht. Another way to do it is to have your SSH server authenticate from an LDAP server or some other centralized authentication source that you may already have set up. As long as each user can get shell access on the machine, any SSH authentication mechanism you can think of should work. Ein anderer Weg ist, einen LDAP-Server zur Authentifizierung zu benutzen oder eine andere zentrale Authentifizierungsquelle, die du vielleicht bereits eingerichtet hast. Solange jeder Benutzer Shell-Zugriff zu der Maschine hat, sollte jede SSH-Authentifizierungsmethode funktionieren, die du dir vorstellen kannst. 6.5 Generating Your SSH Public Key 6.6 Generiere deinen öffentlichen SSH-Schlüssel That being said, many Git servers authenticate using SSH public keys. In order to provide a public key, each user in your system must generate one if they don t already have one. This process is similar across all operating systems. First, you should check to make sure you don t already have a key. By default, a user s SSH keys are stored in that user s ~/.ssh directory. You can easily check to see if you have a key already by going to that directory and listing the contents: Darüber hinaus benutzen viele Git-Server öffentliche SSH-Schlüssel zur Authentifizierung. Um einen öffentlichen Schlüssel bereitzustellen muss jeder Benutzer deines Systems einen solchen Schlüssel generieren, falls sie noch keinen haben. Dieser Prozess ist bei allen Betriebssystemen ähnlich. Als erstes solltest du überprüfen, ob du nicht schon einen Schlüssel hast. Standardmäßig werden die SSH- Schlüssel der Benutzer in ihrem ~/.ssh-verzeichnis gespeichert. Du kannst einfach überprüfen, ob du einen Schlüssel hast, indem du in das Verzeichnis gehst und den Inhalt auflistest: $ cd ~/.ssh 111

126 Chapter 6 Git auf dem Server Scott Chacon Pro Git $ ls authorized_keys2 id_dsa known_hosts config You re looking for a pair of files named something and, where the something is usually id_dsa or id_rsa. file is your public key, and the other file is your private key. If you don t have these files (or you don t even have a.ssh directory), you can create them by running a program called ssh-keygen, which is provided with the SSH package on Linux/Mac systems and comes with the MSysGit package on Windows: Du suchst nach Paar Dateien namens irgendetwas und, die Datei irgendetwas heißt normalerweise id_dsa oder id_rsa. ist dein öffentlicher Schlüssel und die andere Datei ist dein privater Schlüssel. Wenn du diese Dateien nicht hast (oder gar kein.ssh-verzeichnis hast), kannst du sie mit dem Ausführen des Programms ssh-keygen erzeugen. Das Programm wird mit dem SSH-Paket auf Linux/Mac-Systemen mitgeliefert und kommt mit dem MSysGit-Paket unter Windows: $ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/Users/schacon/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /Users/schacon/.ssh/id_rsa. Your public key has been saved in /Users/schacon/.ssh/ The key fingerprint is: 43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3a First it confirms where you want to save the key (.ssh/id_rsa), and then it asks twice for a passphrase, which you can leave empty if you don t want to type a password when you use the key. Zunächst wird bestätigt, wo du den Schlüssel speichern möchtest (.ssh/id_rsa) und dann wird zweimal nach der Passphrase gefragt, die du leer lassen kannst, wenn du kein Passwort bei der Benutzung des Schlüssels eintippen möchtest. Now, each user that does this has to send their public key to you or whoever is administrating the Git server (assuming you re using an SSH server setup that requires public keys). All they have to do is copy the contents of file and it. The public keys look something like this: Jeder Benutzer der dies macht, muss seinen öffentlichen Schlüssel an sich senden oder wer auch immer den Git-Server administriert (angenommen du benutzt eine SSH-Server Konfiguration, die öffentliche Schlüssel benötigt). Alles was die Benutzer tun müssen ist, den Inhalt zu kopieren und an dich per zu schicken. Der öffentliche Schlüssel sieht etwa wie folgt aus: $ cat ~/.ssh/ ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAklOUpkDHrfHY17SbrmTIpNLTGK9Tjom/BWDSU GPl+nafzlHDTYW7hdI4yZ5ew18JH4JW9jbhUFrviQzM7xlELEVf4h9lFX5QVkbPppSwg0cda3 Pbv7kOdJ/MTyBlWXFCR+HAo3FXRitBqxiX1nKhXpHAZsMciLq8V6RjsNAQwdsdMFvSlVK/7XA t3faojoasncm1q9x5+3v0ww68/eifmb1zuufljqjkprrx88xypndvjynby6vw/pb0rwert/en mz+aw4ozpntpi89zpmvmluayrd2ce86z/il8b+gw3r3+1nkatmikjn2so1d01qratlmqvssbx NrRFi9wrf+M7Q== 112

127 Scott Chacon Pro Git Section 6.7 Setting Up the Server For a more in-depth tutorial on creating an SSH key on multiple operating systems, see the GitHub guide on SSH keys at Eine detailliertere Anleitung zur Erstellung eines SSH-Schlüssels unter den verschiedenen Betriebssystemen ist der GitHub-Leitfaden für SSH-Schlüssel unter providing-your-ssh-key. 6.7 Setting Up the Server 6.8 Einrichten des Servers Let s walk through setting up SSH access on the server side. In this example, you ll use the authorized_keys method for authenticating your users. We also assume you re running a standard Linux distribution like Ubuntu. First, you create a git user and a.ssh directory for that user. Nun kommen wir zur Einrichtung des SSH-Zugangs auf der Server-Seite. In diesem Beispiel verwendest du die authorized_keys-methode zur Authentifizierung der Benutzer. Wir nehmen auch an, dass du eine gebräuchliche Linux-Distribution wie Ubuntu verwendest. Zuerst erstellst du den Benutzer git und ein.ssh-verzeichnis für diesen Benutzer. $ sudo adduser git $ su git $ cd $ mkdir.ssh Next, you need to add some developer SSH public keys to the authorized_keys file for that user. Let s assume you ve received a few keys by and saved them to temporary files. Again, the public keys look something like this: Als nächstes ist es nötig, einige öffentliche SSH-Schlüssel der Entwickler zu der authorized_keys- Datei des Benutzers hinzuzufügen. Nehmen wir an, dass du ein paar Schlüssel per empfangen hast und diese in temporären Dateien gespeichert hast. Die öffentlichen Schlüssel sehen wieder etwa wie folgt aus: $ cat /tmp/ ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L ojg6rs6hpb09j9r/t17/x4lhja0f3fr1rp6kybrswj2athgw6hxlm9/5zytk6ztg3rpkk+4k Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq dav8jggjicuvax2t9va5 gsg-keypair You just append them to your authorized_keys file: Du hängst sie einfach an deine authorized_keys-datei an: $ cat /tmp/ >> ~/.ssh/authorized_keys $ cat /tmp/ >> ~/.ssh/authorized_keys $ cat /tmp/ >> ~/.ssh/authorized_keys 113

128 Chapter 6 Git auf dem Server Scott Chacon Pro Git Now, you can set up an empty repository for them by running git init with the --bare option, which initializes the repository without a working directory: Jetzt kannst du einen leeren Ordner für sie anlegen, indem du den Befehl git init mit der Option --bare ausführst. Damit wird ein Repository ohne ein Arbeitsverzeichnis erzeugt. $ cd /opt/git $ mkdir project.git $ cd project.git $ git --bare init Then, John, Josie, or Jessica can push the first version of their project into that repository by adding it as a remote and pushing up a branch. Note that someone must shell onto the machine and create a bare repository every time you want to add a project. Let s use gitserver as the hostname of the server on which you ve set up your git user and repository. If you re running it internally, and you set up DNS for gitserver to point to that server, then you can use the commands pretty much as is: Dann können John, Josie oder Jessica die erste Version ihres Projektes in das Repository hochladen, indem sie es als externes Repository hinzufügen und einen Branch hochladen. Beachte, dass sich bei jeder Projekterstellung jemand mit der Maschine auf eine Shell verbinden muss, um ein einfaches Repository zu erzeugen. Lass uns gitserver als Hostnamen des Servers verwenden, auf dem du den Benutzer git und das Repository eingerichtet hast. Wenn du den Server intern betreibst und das DNS so eingerichtet hast, dass gitserver auf den Server zeigt, dann kannst du die Befehle ziemlich wie hier benutzen: # on Johns computer $ cd myproject $ git init $ git add. $ git commit -m 'initial commit' $ git remote add origin $ git push origin master At this point, the others can clone it down and push changes back up just as easily: An diesem Punkt können die anderen das Repository klonen und Änderungen ebenso leicht hochladen: $ git clone $ vim README $ git commit -am 'fix for the README file' $ git push origin master With this method, you can quickly get a read/write Git server up and running for a handful of developers. Mit dieser Methode kannst du schnell für eine Handvoll Entwickler einen Lese/Schreib Git- Server zum Laufen bekommen. 114

129 Scott Chacon Pro Git Section 6.8 Einrichten des Servers As an extra precaution, you can easily restrict the git user to only doing Git activities with a limited shell tool called git-shell that comes with Git. If you set this as your git user s login shell, then the git user can t have normal shell access to your server. To use this, specify gitshell instead of bash or csh for your user s login shell. To do so, you ll likely have to edit your / etc/passwd file: Als zusätzliche Vorsichtsmaßnahme kannst du den Benutzer git so beschränken, dass er nur Git-Aktivitäten mit einem limitierten Shell-Tool namens git-shell ausführen kann, dass mit Git kommt. Wenn du das als Login-Shell des git -Benutzers einrichtest, dann hat der Benutzer git keinen normalen Shell-Zugriff auf den Server. Zur Benutzung bestimme git-shell anstatt von bash oder csh als Login-Shell deines Benutzers. Um das zu tun wirst du wahrscheinlich deine / etc/passwd editieren: $ sudo vim /etc/passwd At the bottom, you should find a line that looks something like this: Am Ende solltest du eine Zeile finden, die in etwa so aussieht: git:x:1000:1000::/home/git:/bin/sh Change /bin/sh to /usr/bin/git-shell (or run which git-shell to see where it s installed). The line should look something like this: Ändere /bin/sh zu /usr/bin/git-shell (oder führe which git-shell aus, um zu sehen, wo es installiert ist). Die Zeile sollte in etwa so aussehen: git:x:1000:1000::/home/git:/usr/bin/git-shell Now, the git user can only use the SSH connection to push and pull Git repositories and can t shell onto the machine. If you try, you ll see a login rejection like this: Jetzt kann der git -Benutzer die SSH-Verbindung nur noch verwenden, um Git-Repositories hochzuladen und herunterzuladen. Der Benutzer kann sich nicht mehr per Shell zur Maschine verbinden. Wenn du es versuchst, siehst du eine Login-Ablehnung wie diese: $ ssh fatal: What do you think I am? A shell? Connection to gitserver closed. 115

130 Chapter 6 Git auf dem Server Scott Chacon Pro Git 6.9 Public Access 6.10 Öffentlicher Zugang What if you want anonymous read access to your project? Perhaps instead of hosting an internal private project, you want to host an open source project. Or maybe you have a bunch of automated build servers or continuous integration servers that change a lot, and you don t want to have to generate SSH keys all the time you just want to add simple anonymous read access. Was ist, wenn du anonymen Lese-Zugriff zu deinem Projekt möchtest? Vielleicht möchtest du ein Open-Source-Projekt anstatt einem internen, privaten Projekt hosten. Oder du hast ein paar automatisierte Build-Server oder einen kontinuierlichen Integrationsserver, der sich oft verändert (xxx), und du möchtest nicht die ganze Zeit SSH-Schlüssel generieren - du willst nur einen einfachen anonymen Lese-Zugriff hinzufügen. Probably the simplest way for smaller setups is to run a static web server with its document root where your Git repositories are, and then enable that post-update hook we mentioned in the first section of this chapter. Let s work from the previous example. Say you have your repositories in the / opt/git directory, and an Apache server is running on your machine. Again, you can use any web server for this; but as an example, we ll demonstrate some basic Apache configurations that should give you an idea of what you might need. Der wahrscheinlich einfachste Weg für kleinere Konfigurationen ist, einen statischen Web-Server laufen zu lassen, mit dem gleichen Dokumenten-Basisverzeichnis wie deinen Git-Repositories. Dann aktivierst du den post-update hook (xxx), den wir im ersten Abschnitt dieses Kapitels erwähnt haben. Gehen wir vom vorherigen Beispiel aus. Sagen wir, du hast deine Repositories im Verzeichnis /opt/git und ein Apache-Server läuft auf deiner Maschine. Du kannst einen beliebigen Web- Server dafür benutzen. Aber als Beispiel zeigen wir einige grundlegende Apache-Konfigurationen, die dir eine Vorstellung geben sollten, was du vielleicht brauchst. First you need to enable the hook: Zuerst musst den den hook (xxx) aktivieren: $ cd project.git $ mv hooks/post-update.sample hooks/post-update $ chmod a+x hooks/post-update If you re using a version of Git earlier than 1.6, the mv command isn t necessary Git started naming the hooks examples with the.sample postfix only recently. Wenn du eine Git-Version früher als 1.6 benutzt ist der mv-befehl nicht notwendig - Git begann die Benennung der hooks (xxx) mit der.sample postfix (xxx) erst vor kurzem. What does this post-update hook do? It looks basically like this: Was macht dieser post-update hook (xxx)? Es sieht im Grunde so aus: $ cat.git/hooks/post-update #!/bin/sh exec git-update-server-info 116

131 Scott Chacon Pro Git Section 6.10 Öffentlicher Zugang This means that when you push to the server via SSH, Git will run this command to update the files needed for HTTP fetching. Wenn du etwas auf den Server hochlädst, wird Git diesen Befehl ausführen, um die nötigen Dateien für das HTTP fetching (xxx) zu aktualisieren. Next, you need to add a VirtualHost entry to your Apache configuration with the document root as the root directory of your Git projects. Here, we re assuming that you have wildcard DNS set up to send *.gitserver to whatever box you re using to run all this: Als nächstes musst du einen VirtualHost-Eintrag zu deiner Apache-Konfiguration hinzufügen. Das Basisverzeichnis des Web-Servers muss mit dem Basisverzeichnis deiner Git-Projekte übereinstimmen. Hier nehmen wir an, dass du einen Wildcard-DNS eingerichtet hast, um *.gitserver zu dem Server zu senden, den du verwendest, um all dies laufen zu lassen: <VirtualHost *:80> ServerName git.gitserver DocumentRoot /opt/git <Directory /opt/git/> Order allow, deny allow from all </Directory> </VirtualHost> You ll also need to set the Unix user group of the /opt/git directories to www-data so your web server can read-access the repositories, because the Apache instance running the CGI script will (by default) be running as that user: Du musst auch die Unix-Benutzergruppe des Verzeichnisses /opt/git auf www-data setzen, sodass dein Web-Server die Repositories lesen kann, weil die Apache-Instanz, die das CGI-Skript ausführt, als dieser Benutzer läuft. $ chgrp -R www-data /opt/git When you restart Apache, you should be able to clone your repositories under that directory by specifying the URL for your project: Wenn du Apache neu startest solltest du in der Lage sein, deine Repositories in dem Verzeichnis zu klonen, indem du die URL für dein Projekt angibst. $ git clone This way, you can set up HTTP-based read access to any of your projects for a fair number of users in a few minutes. Another simple option for public unauthenticated access is to start a Git daemon, although that requires you to daemonize the process - we ll cover this option in the next section, if you prefer that route. So kannst du HTTP-basierte Lese-Zugänge zu allen deinen Projekte für eine angemessene Anzahl von Benutzern in ein paar Minuten einrichten. Eine andere einfache Möglichkeit für öffentlichen 117

132 Chapter 6 Git auf dem Server Scott Chacon Pro Git nicht-authentifizierten Zugriff ist, einen Git-Dämonen zu starten. Das erfordert jedoch, dass du den Prozess dämonisierst - wir behandeln diese Option im nächsten Abschnitt, wenn du diesen Weg bevorzugst GitWeb Now that you have basic read/write and read-only access to your project, you may want to set up a simple web-based visualizer. Git comes with a CGI script called GitWeb that is commonly used for this. You can see GitWeb in use at sites like (see Figure 4.1). Figure 6.1: The GitWeb web-based user interface. If you want to check out what GitWeb would look like for your project, Git comes with a command to fire up a temporary instance if you have a lightweight server on your system like lighttpd or webrick. On Linux machines, lighttpd is often installed, so you may be able to get it to run by typing git instaweb in your project directory. If you re running a Mac, Leopard comes preinstalled with Ruby, so webrick may be your best bet. To start instaweb with a non-lighttpd handler, you can run it with the --httpd option. $ git instaweb --httpd=webrick [ :02:21] INFO WEBrick [ :02:21] INFO ruby ( ) [universal-darwin9.0] That starts up an HTTPD server on port 1234 and then automatically starts a web browser that opens on that page. It s pretty easy on your part. When you re done and want to shut down the server, you can run the same command with the --stop option: $ git instaweb --httpd=webrick --stop If you want to run the web interface on a server all the time for your team or for an open source project you re hosting, you ll need to set up the CGI script to be served by your normal web server. Some Linux distributions have a gitweb package that you may be able to install via apt or yum, so you may want to try that first. We ll walk though installing GitWeb manually very quickly. First, you need to get the Git source code, which GitWeb comes with, and generate the custom CGI script: $ git clone git:// $ cd git/ $ make GITWEB_PROJECTROOT="/opt/git" \ prefix=/usr gitweb/gitweb.cgi $ sudo cp -Rf gitweb /var/www/ 118

ReadMe zur Installation der BRICKware for Windows, Version 6.1.2. ReadMe on Installing BRICKware for Windows, Version 6.1.2

ReadMe zur Installation der BRICKware for Windows, Version 6.1.2. ReadMe on Installing BRICKware for Windows, Version 6.1.2 ReadMe zur Installation der BRICKware for Windows, Version 6.1.2 Seiten 2-4 ReadMe on Installing BRICKware for Windows, Version 6.1.2 Pages 5/6 BRICKware for Windows ReadMe 1 1 BRICKware for Windows, Version


Git eine kurze Einführung

Git eine kurze Einführung Git eine kurze Einführung Malte Schmitz ~ Mai 2012 1 Ziele dieses Vortrags 1. Git installieren und einrichten können. 2. Idee von verteilter Versionskontrolle verstehen. 3. Idee der nichtlinearen Entwicklung


Spiel, Spaß und Spannung mit Git

Spiel, Spaß und Spannung mit Git Spiel, Spaß und Spannung mit Git 2-3 Std-Workshop Meine Person??? Spiel, Spaß und Spannung mit Git 2 Ziel Du kannst Git auf einem Windows- oder Linux- Rechner installieren und konfigurieren Du kennst die


Git eine kurze Einführung. Malte Schmitz ~ Mai 2012

Git eine kurze Einführung. Malte Schmitz ~ Mai 2012 eine kurze Einführung ~ Mai 2012 Ziele dieses Vortrags 1. installieren und einrichten können. 2. Idee von verteilter Versionskontrolle verstehen. 3. Idee der nichtlinearen Entwicklung verstehen. 4. Mit


Versionkontrolle mit git

Versionkontrolle mit git Versionkontrolle mit git Wer bin ich? Wer bin ich? Federico Hernandez Wer bin ich? Darmstadt Wer bin ich? Göteborg, Schweden Wer bin ich? Mathematiker Wer bin ich? Senior Linux/Unix System Administrator


Eine Einführung in das verteilte Quelltextverwaltungssystem Git

Eine Einführung in das verteilte Quelltextverwaltungssystem Git Eine Einführung in das verteilte Quelltextverwaltungssystem Git B.Sc. Daniel Baulig Fachhochschule Frankfurt am Main University of Applied Sciences 2. November 2012 Übersicht 1 Einführung Über mich Versions-was?


Git - Fast Version Control System

Git - Fast Version Control System Git - Fast Version Control System Sebastian Harl Astronomisches Institut der Universität Erlangen-Nürnberg 17. Oktober 2008 Was ist Git? VCS (Version Control


Versionsverwaltung für die KU Betriebssysteme. Eine Einführung

Versionsverwaltung für die KU Betriebssysteme. Eine Einführung Versionsverwaltung für die KU Betriebssysteme Eine Einführung 1 1 Versionsverwaltung? Wozu? Nachvollziehbarkeit Wer hat was wann geändert Wiederherstellbarkeit kaputteditiert Wartbarkeit Verschiedene Versionen


git Alexander Bernauer Rico Schiekel

git Alexander Bernauer <> Rico Schiekel <> git Alexander Bernauer Rico Schiekel Big Picture Beispiel Open-Source-Projekt öffentliches Repository öffentlicher Fork push fetch push Haupt- Entwickler fetch Contributer


git & git-flow Jens Sandmann 14.12.2013 Warpzone Münster e.v. Jens Sandmann (WZ) git & git-flow 14.12.2013 1 / 31

git & git-flow Jens Sandmann 14.12.2013 Warpzone Münster e.v. Jens Sandmann (WZ) git & git-flow 14.12.2013 1 / 31 git & git-flow Jens Sandmann Warpzone Münster e.v. 14.12.2013 Jens Sandmann (WZ) git & git-flow 14.12.2013 1 / 31 Überblick 1 git Versionskontrolle Allgemein VCS mit git 2 git flow 3 git nutzen 4 Anhang


Einführung in git. Ben Oswald. 27. April 2014. Im Rahmen der Vorlesung Entwicklung mobiler Anwendungen

Einführung in git. Ben Oswald. 27. April 2014. Im Rahmen der Vorlesung Entwicklung mobiler Anwendungen Einführung in git Im Rahmen der Vorlesung Entwicklung mobiler Anwendungen Ben Oswald 27. April 2014 Inhaltsverzeichnis 1 Einleitung 1 1.1 Was ist git?..................................... 1 1.2 Warum sollten


Einführung in Git. Dirk Deimeke. 19. August 2013. My own IT. ddeimeke (My own IT) Einführung in Git 19. August 2013 1 / 23

Einführung in Git. Dirk Deimeke. 19. August 2013. My own IT. ddeimeke (My own IT) Einführung in Git 19. August 2013 1 / 23 Einführung in Git Dirk Deimeke My own IT 19. August 2013 ddeimeke (My own IT) Einführung in Git 19. August 2013 1 / 23 Inhalt 1 Etwas Theorie Basiswissen Git 2 Praxis Installation Erstes Repository Besonderheiten


KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich?

KURZANLEITUNG. Firmware-Upgrade: Wie geht das eigentlich? KURZANLEITUNG Firmware-Upgrade: Wie geht das eigentlich? Die Firmware ist eine Software, die auf der IP-Kamera installiert ist und alle Funktionen des Gerätes steuert. Nach dem Firmware-Update stehen Ihnen


Von SVN zu Git. Daniel Willmann 2011-10-18 cbna

Von SVN zu Git. Daniel Willmann <> 2011-10-18 cbna Von SVN zu Git Daniel Willmann 2011-10-18 cbna Inhalt Einführung Git für SVN Benutzer Weitergehende Konzepte Zusammenfassung Daniel Willmann Von SVN zu Git 2 Über den Vortragenden





Gitting started. Christian Neukirchen. 14dec2011

Gitting started. Christian Neukirchen. 14dec2011 Gitting started Christian Neukirchen 14dec2011 Wieso Versionskontrolle? Erste Schritte Branches Zusammenarbeit Nicht-trivale Features GUI Ausblick Agenda Wieso Versionskontrolle? Den Verlauf eines Projekts


Einführung in git. Johannes Gilger & Matthias Lederhofer. Rechen- und Kommunikationszentrum der RWTH Aachen Network Operation Center. 14.

Einführung in git. Johannes Gilger & Matthias Lederhofer. Rechen- und Kommunikationszentrum der RWTH Aachen Network Operation Center. 14. Johannes Gilger & Matthias Lederhofer der RWTH Aachen Network Operation Center 14. Juli 2010 Übersicht Begriffe in der Versionsverwaltung Unterschiede zentrale und dezentrale VCS Warum man git benutzen


Der Adapter Z250I / Z270I lässt sich auf folgenden Betriebssystemen installieren:

Der Adapter Z250I / Z270I lässt sich auf folgenden Betriebssystemen installieren: Installationshinweise Z250I / Z270I Adapter IR USB Installation hints Z250I / Z270I Adapter IR USB 06/07 (Laden Sie den Treiber vom WEB, entpacken Sie ihn in ein leeres Verzeichnis und geben Sie dieses



Versionskontrollsysteme Versionskontrollsysteme Erfassung von Änderungen an Dateien Protokollierung von Änderungen Wiederherstellung alter Zustände Archivierung der gesamten Historie Koordinierung des gemeinsamen Zugriffs Verzweigung


NEWSLETTER. FileDirector Version 2.5 Novelties. Filing system designer. Filing system in WinClient

NEWSLETTER. FileDirector Version 2.5 Novelties. Filing system designer. Filing system in WinClient Filing system designer FileDirector Version 2.5 Novelties FileDirector offers an easy way to design the filing system in WinClient. The filing system provides an Explorer-like structure in WinClient. The



p^db=`oj===pìééçêíáåñçêã~íáçå= p^db=`oj===pìééçêíáåñçêã~íáçå= How to Disable User Account Control (UAC) in Windows Vista You are attempting to install or uninstall ACT! when Windows does not allow you access to needed files or folders.


Einführung in Verteilte Versionskontrollsysteme. am Beispiel von Git

Einführung in Verteilte Versionskontrollsysteme. am Beispiel von Git Einführung in Verteilte Versionskontrollsysteme am Beispiel von Git Diplominformatiker (BA), Git Benutzer seit 2009 Daniel Böhmer Leibniz Institut für Troposphärenforschung 8. März 2012 Verteilte Versionskontrollsysteme/Git

Mehr Sie haben nun Office über Office365 bezogen. Ihr Account wird in Kürze in dem Office365 Portal angelegt. Anschließend können Sie, wie unten beschrieben, die Software beziehen. Congratulations, you have


Linux Cafe 2013 11 11. Referent: Bernd Strößenreuther

Linux Cafe 2013 11 11. Referent: Bernd Strößenreuther Versionsverwaltung mit Git Linux Cafe 2013 11 11 Referent: Bernd Strößenreuther mailto:linux Lizenz Sie dürfen dieses Dokument verwenden unter den Bedingungen der Creative Commons



ONLINE LICENCE GENERATOR Index Introduction... 2 Change language of the User Interface... 3 Menubar... 4 Sold Software... 5 Explanations of the choices:... 5 Call of a licence:... 7 Last query step... 9 Call multiple licenses:...


Einstieg in Git. Lukáš Kubánek 19.10.2011

Einstieg in Git. Lukáš Kubánek 19.10.2011 Lukáš Kubánek 19.10.2011 1 EINFÜHRUNG EINFÜHRUNG Was ist Git? EINFÜHRUNG Intention der Entwicklung Me personally, I want to have something that is very repeatable and non-clever. Something I understand


Subversion. Einstieg in die. Versionskontrolle

Subversion. Einstieg in die. Versionskontrolle Versionskontrolle mit Subversion Einstieg in die Versionskontrolle Dipl.Ing.(FH) K. H. Marbaise Agenda Wozu Versionskontrolle? Was leistet Versionskontrolle? Historie zu Subversion Projekt Handling Installation


Aber genau deshalb möchte ich Ihre Aufmehrsamkeit darauf lenken und Sie dazu animieren, der Eventualität durch geeignete Gegenmaßnahmen zu begegnen.

Aber genau deshalb möchte ich Ihre Aufmehrsamkeit darauf lenken und Sie dazu animieren, der Eventualität durch geeignete Gegenmaßnahmen zu begegnen. NetWorker - Allgemein Tip 618, Seite 1/5 Das Desaster Recovery (mmrecov) ist evtl. nicht mehr möglich, wenn der Boostrap Save Set auf einem AFTD Volume auf einem (Data Domain) CIFS Share gespeichert ist!



p^db=`oj===pìééçêíáåñçêã~íáçå= p^db=`oj===pìééçêíáåñçêã~íáçå= Error: "Could not connect to the SQL Server Instance" or "Failed to open a connection to the database." When you attempt to launch ACT! by Sage or ACT by Sage Premium for


Cameraserver mini. commissioning. Ihre Vision ist unsere Aufgabe

Cameraserver mini. commissioning. Ihre Vision ist unsere Aufgabe Cameraserver mini commissioning Page 1 Cameraserver - commissioning Contents 1. Plug IN... 3 2. Turn ON... 3 3. Network configuration... 4 4. Client-Installation... 6 4.1 Desktop Client... 6 4.2 Silverlight


Exercise (Part XI) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1

Exercise (Part XI) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1 Exercise (Part XI) Notes: The exercise is based on Microsoft Dynamics CRM Online. For all screenshots: Copyright Microsoft Corporation. The sign ## is you personal number to be used in all exercises. All


Apache Subversion (SVN)

Apache Subversion (SVN) Apache Subversion (SVN) Datamining und Sequenzanalyse Marvin Meusel, Sascha Winter 18.10.2013 Apache Subversion (SVN) Datamining und Sequenzanalyse Marvin Meusel, Sascha Winter 18.10.2013 git Datamining


Dezentrale Versionsverwaltung

Dezentrale Versionsverwaltung Dezentrale Versionsverwaltung mit GIT with that guy 14.08.2012 Lars Kumbier 1 Versionsverwaltung? 14.08.2012 Lars Kumbier 2 Versionsverwaltung? Speichern unterschiedlicher Entwicklungsschritte (oder Versionen)


NVR Mobile Viewer for iphone/ipad/ipod Touch

NVR Mobile Viewer for iphone/ipad/ipod Touch NVR Mobile Viewer for iphone/ipad/ipod Touch Quick Installation Guide DN-16111 DN-16112 DN16113 2 DN-16111, DN-16112, DN-16113 for Mobile ios Quick Guide Table of Contents Download and Install the App...


Instruktionen Mozilla Thunderbird Seite 1

Instruktionen Mozilla Thunderbird Seite 1 Instruktionen Mozilla Thunderbird Seite 1 Instruktionen Mozilla Thunderbird Dieses Handbuch wird für Benutzer geschrieben, die bereits ein E-Mail-Konto zusammenbauen lassen im Mozilla Thunderbird und wird


Git Workshop. LiWoLi 2012. Florian Preinstorfer. Wolfgang Silbermayr 25.05.2012.

Git Workshop. LiWoLi 2012. Florian Preinstorfer. Wolfgang Silbermayr 25.05.2012. Git Workshop LiWoLi 2012 Florian Preinstorfer Wolfgang Silbermayr 25.05.2012 This work is licensed under the Creative Commons Attribution-ShareAlike 3.0 Austria license


HIR Method & Tools for Fit Gap analysis

HIR Method & Tools for Fit Gap analysis HIR Method & Tools for Fit Gap analysis Based on a Powermax APML example 1 Base for all: The Processes HIR-Method for Template Checks, Fit Gap-Analysis, Change-, Quality- & Risk- Management etc. Main processes


Git Eine Einführung. LinuxTag 2013, Berlin. Julius Plenz. 22. Mai 2013

Git Eine Einführung. LinuxTag 2013, Berlin. Julius Plenz. 22. Mai 2013 Git Eine Einführung LinuxTag 2013, Berlin Julius Plenz 22. Mai 2013 Ablauf Versionskontrolle: Zentral vs. Dezentral Historischer Kurzabriss zu Git Das Objektmodell wie funktioniert Git? Merge vs. Rebase


Einführung Git Interna Workflows Referenzen. Git. Fast Version Control System. Michael Kuhn

Einführung Git Interna Workflows Referenzen. Git. Fast Version Control System. Michael Kuhn Git Fast Version Control System Michael Kuhn Arbeitsbereich Wissenschaftliches Rechnen Fachbereich Informatik Universität Hamburg 2011-09-28 1 / 16 1 Einführung Überblick


Medieninformatik Praktikum. Jens Rademacher 14.07.2013

Medieninformatik Praktikum. Jens Rademacher 14.07.2013 mit mit Medieninformatik Praktikum 14.07.2013 1 / 13 mit 2 / 13 Nutzen von und an en mit Verwaltung unterschiedlicher Versionen einer Datei Protokollierung von Änderungen (Änderung, Zeitpunkt, Person)


How to use the large-capacity computer Lilli? IMPORTANT: Access only on JKU Campus!! Using Windows:

How to use the large-capacity computer Lilli? IMPORTANT: Access only on JKU Campus!! Using Windows: How to use the large-capacity computer Lilli? IMPORTANT: Access only on JKU Campus!! Using Windows: In order to connect to Lilli you need to install the program PUTTY. The program enables you to create


Ingenics Project Portal

Ingenics Project Portal Version: 00; Status: E Seite: 1/6 This document is drawn to show the functions of the project portal developed by Ingenics AG. To use the portal enter the following URL in your Browser:


Torsten Flatter inovex GmbH. "Git.NET" gibt's nicht?

Torsten Flatter inovex GmbH. Git.NET gibt's nicht? Torsten Flatter inovex GmbH "Git.NET" gibt's nicht? Vorstellung Torsten Flatter inovex GmbH.NET / C# seit 2004 VSS, CVS, SVN, TFS, hq, git Enterprise-Umfeld Agenda Überblick Grundlagen Einsatzbereiche


Versionsverwaltung von Softwareartefakten. 21. Oktober 2014

Versionsverwaltung von Softwareartefakten. 21. Oktober 2014 Versionsverwaltung von Softwareartefakten 21. Oktober 2014 Überblick Wie verwaltet man Softwareartefakte? Versionskontrolle für verschiedene Softwareartefakte: Anforderungsdokumente, Modelle, Code, Testdateien,


Titelbild1 ANSYS. Customer Portal LogIn

Titelbild1 ANSYS. Customer Portal LogIn Titelbild1 ANSYS Customer Portal LogIn 1 Neuanmeldung Neuanmeldung: Bitte Not yet a member anklicken Adressen-Check Adressdaten eintragen Customer No. ist hier bereits erforderlich HERE - Button Hier nochmal


Versionierung und Bugtracking mit Git(Hub)

Versionierung und Bugtracking mit Git(Hub) Semesterprojekt Verteilte Echtzeitrecherche in Genomdaten Versionierung und Bugtracking mit Git(Hub) Marc Bux ( Ziele der Versionierung Revisionsgeschichte eines Projekts erhalten


31.01.2013. Vorlesung Programmieren. Versionskontrollsysteme. Ziele von VCS. Versionskontrolle

31.01.2013. Vorlesung Programmieren. Versionskontrollsysteme. Ziele von VCS. Versionskontrolle Vorlesung Programmieren Versionskontrolle Dr. Dennis Pfisterer Institut für Telematik, Universität zu Lübeck Versionskontrollsysteme Wie organisiert man die


1. General information... 2 2. Login... 2 3. Home... 3 4. Current applications... 3

1. General information... 2 2. Login... 2 3. Home... 3 4. Current applications... 3 User Manual for Marketing Authorisation and Lifecycle Management of Medicines Inhalt: User Manual for Marketing Authorisation and Lifecycle Management of Medicines... 1 1. General information... 2 2. Login...


Invitation - Benutzerhandbuch. User Manual. User Manual. I. Deutsch 2. 1. Produktübersicht 2. 1.1. Beschreibung... 2

Invitation - Benutzerhandbuch. User Manual. User Manual. I. Deutsch 2. 1. Produktübersicht 2. 1.1. Beschreibung... 2 Invitation - Inhaltsverzeichnis I. Deutsch 2 1. Produktübersicht 2 1.1. Beschreibung......................................... 2 2. Installation und Konfiguration 2 2.1. Installation...........................................


Symbio system requirements. Version 5.1

Symbio system requirements. Version 5.1 Symbio system requirements Version 5.1 From: January 2016 2016 Ploetz + Zeller GmbH Symbio system requirements 2 Content 1 Symbio Web... 3 1.1 Overview... 3 1.1.1 Single server installation... 3 1.1.2


Worx Landroid - Software Update

Worx Landroid - Software Update Worx Landroid - Software Update WORX Landroid Software Update für Anwender 30.04.2015 Website: Direct Direkter Link Link for auf the Update: Update:


Concept. Chapter. Locking daemon over CIFS for Verantwortlich

Concept. Chapter. Locking daemon over CIFS for Verantwortlich FOSS-Group GmbH Bismarckallee 9 4D-79098 Freiburg Tel. +41 (0)61 751 72 80 Fax +41 (0)61 751 78 79 Mail: Concept OSBD Chapter Locking daemon over CIFS for


There are 10 weeks this summer vacation the weeks beginning: June 23, June 30, July 7, July 14, July 21, Jul 28, Aug 4, Aug 11, Aug 18, Aug 25

There are 10 weeks this summer vacation the weeks beginning: June 23, June 30, July 7, July 14, July 21, Jul 28, Aug 4, Aug 11, Aug 18, Aug 25 Name: AP Deutsch Sommerpaket 2014 The AP German exam is designed to test your language proficiency your ability to use the German language to speak, listen, read and write. All the grammar concepts and


git Änderungen verwalten mit git

git Änderungen verwalten mit git Änderungen verwalten mit git Wie arbeitet man am besten an einem Protokoll zusammen? PeP et al. Toolbox, 2014 2 Idee: Austausch über Mails PeP et al. Toolbox, 2014 3 Mails: Probleme Risiko, dass Änderungen


Exercise (Part II) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1

Exercise (Part II) Anastasia Mochalova, Lehrstuhl für ABWL und Wirtschaftsinformatik, Kath. Universität Eichstätt-Ingolstadt 1 Exercise (Part II) Notes: The exercise is based on Microsoft Dynamics CRM Online. For all screenshots: Copyright Microsoft Corporation. The sign ## is you personal number to be used in all exercises. All



XV1100K(C)/XV1100SK(C) Lexware Warenwirtschaft Pro XV1100K(C)/XV1100SK(C) All rights reserverd. Any reprinting or unauthorized use wihout the written permission of Lexware Warenwirtschaft Pro Corporation, is expressly prohibited.


Frequently asked Questions for Kaercher Citrix (

Frequently asked Questions for Kaercher Citrix ( Frequently asked Questions for Kaercher Citrix ( Inhalt Content Citrix-Anmeldung Login to Citrix Was bedeutet PIN und Token (bei Anmeldungen aus dem Internet)? What does PIN and Token


SELF-STUDY DIARY (or Lerntagebuch) GER102

SELF-STUDY DIARY (or Lerntagebuch) GER102 SELF-STUDY DIARY (or Lerntagebuch) GER102 This diary has several aims: To show evidence of your independent work by using an electronic Portfolio (i.e. the Mahara e-portfolio) To motivate you to work regularly


USB Treiber updaten unter Windows 7/Vista

USB Treiber updaten unter Windows 7/Vista USB Treiber updaten unter Windows 7/Vista Hinweis: Für den Downloader ist momentan keine 64 Bit Version erhältlich. Der Downloader ist nur kompatibel mit 32 Bit Versionen von Windows 7/Vista. Für den Einsatz


Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision

Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Infrastructure as a Service (IaaS) Solutions for Online Game Service Provision Zielsetzung: System Verwendung von Cloud-Systemen für das Hosting von online Spielen (IaaS) Reservieren/Buchen von Resources


Praktikum Entwicklung Mediensysteme (für Master)

Praktikum Entwicklung Mediensysteme (für Master) Praktikum Entwicklung Mediensysteme (für Master) Organisatorisches Today Schedule Organizational Stuff Introduction to Android Exercise 1 2 Schedule Phase 1 Individual Phase: Introduction to basics about



XV1100K(C)/XV1100SK(C) Lexware Financial Office Premium Handwerk XV1100K(C)/XV1100SK(C) All rights reserverd. Any reprinting or unauthorized use wihout the written permission of Lexware Financial Office Premium Handwerk Corporation,


Software development with continuous integration

Software development with continuous integration Software development with continuous integration (FESG/MPIfR) (FESG) 1 A critical view on scientific software Tendency to become complex and unstructured Highly


UM ALLE DATEN ZU KOPIEREN. ZUNÄCHST die Daten des alten Telefons auf einen Computer kopieren

UM ALLE DATEN ZU KOPIEREN. ZUNÄCHST die Daten des alten Telefons auf einen Computer kopieren LUMIA mit WP8 IPHONE Daten des alten Telefons auf einen Computer kopieren Software von auf Ihrem PC oder Mac. verbinden Sie Ihr altes Telefon über 3. Wenn Sie Outlook nutzen, öffnen


Crashkurs Subversion / Trac / Provisioning. Jan Zieschang, 04.01.2008, Berlin

Crashkurs Subversion / Trac / Provisioning. Jan Zieschang, 04.01.2008, Berlin Crashkurs Subversion / Trac / Provisioning Jan Zieschang, 04.01.2008, Berlin Agenda 2 Subversion Das SCM TortoiseSvn Der Client Trac Das Tracking-Tool Provisioning Das Provisioning Tool Arbeiten mit Subversion/TortoiseSvn


Linux Anwender-Security. Dr. Markus Tauber 26/04/2013

Linux Anwender-Security. Dr. Markus Tauber 26/04/2013 Linux Anwender-Security Dr. Markus Tauber 26/04/2013 Inhalt Benutzer(selbst)Schutz - für den interessierten Anwender Praktische Beispiele und Hintergründe (Wie & Warum) Basierend





Verteile Revisionskontrolle mit GIT

Verteile Revisionskontrolle mit GIT Verteile Revisionskontrolle mit GIT Christian Thäter 25. Juni 2007 Über diesen Vortrag 1. Was ist Revisionskontrolle? 2. Wie funktioniert GIT? 3. GIT Workshop Fragen werden nach jedem Abschnitt

Mehr E-License - Product Activation E-License - Produktaktivierung E-License - Product Activation E-License - Produktaktivierung E-License - Product Activation E-License - Produktaktivierung A-1 Yellow Tools E-License Activation Yellow Tools E-License Activation A-2 Dear user, thanks for purchasing one of our


Git. Dezentrale Versionsverwaltung im Team Grundlagen und Workflows. Rene Preißel Björn Stachmann. 2., aktualisierte und erweiterte Auflage

Git. Dezentrale Versionsverwaltung im Team Grundlagen und Workflows. Rene Preißel Björn Stachmann. 2., aktualisierte und erweiterte Auflage Rene Preißel Björn Stachmann Git / Dezentrale Versionsverwaltung im Team Grundlagen und Workflows 2., aktualisierte und erweiterte Auflage fäjj dpunkt.verlag XV Erste Schritte 1 Grundlegende Konzepte 1


Thema: Sonnenuhren (7.Jahrgangsstufe)

Thema: Sonnenuhren (7.Jahrgangsstufe) Thema: Sonnenuhren (7.Jahrgangsstufe) Im Rahmen des Physikunterrichts haben die Schüler der Klasse 7b mit dem Bau einfacher Sonnenuhren beschäftigt. Die Motivation lieferte eine Seite im Physikbuch. Grundidee


Stocktaking with GLPI

Stocktaking with GLPI Stocktaking with GLPI Karsten Becker Ecologic Institute Table of content icke About Ecologic Institute Why you need stocktaking Architecture Features Demo 2 icke Karsten Becker living in Berlin first computer:


Isabel Arnold CICS Technical Sales Germany z/os Explorer. 2014 IBM Corporation

Isabel Arnold CICS Technical Sales Germany z/os Explorer. 2014 IBM Corporation Isabel Arnold CICS Technical Sales Germany z/os Explorer Agenda Introduction and Background Why do you want z/os Explorer? What does z/os Explorer do? z/os Resource Management


Julius Plenz. Valentin Haenel. Git. Verteilte Versionsverwaltung für Code Dokumente. 2. Auflage. Open Source Press

Julius Plenz. Valentin Haenel. Git. Verteilte Versionsverwaltung für Code Dokumente. 2. Auflage. Open Source Press Valentin Haenel Julius Plenz Git Verteilte Versionsverwaltung für Code Dokumente 2. Auflage Open Source Press Inhaltsverzeichnis Vorwort 11 I Grundlagen 17 1 Einführung und erste Schritte 19 1.1 Grundbegriffe


ALL1681 Wireless 802.11g Powerline Router Quick Installation Guide

ALL1681 Wireless 802.11g Powerline Router Quick Installation Guide ALL1681 Wireless 802.11g Powerline Router Quick Installation Guide 1 SET ALL1681 Upon you receive your wireless Router, please check that the following contents are packaged: - Powerline Wireless Router


Login data for HAW Mailer, Emil und Helios

Login data for HAW Mailer, Emil und Helios Login data for HAW Mailer, Emil und Helios Es gibt an der HAW Hamburg seit einiger Zeit sehr gute Online Systeme für die Studenten. Jeder Student erhält zu Beginn des Studiums einen Account für alle Online


Praktikum Ingenieurinformatik (PI)

Praktikum Ingenieurinformatik (PI) Praktikum Ingenieurinformatik (PI) Verteilte Versionskontrolle mit Git und Github Björn Meyer Fachgebiet Technische Informatik 1 Agenda Einleitung Motivation Versionskontrolle Ansätze Git Funktionen Arbeiten


Installationshinweise Z501J / Z501K Adapter IrDa USB Installation hints Z501J / Z501K Adapter IrDa USB

Installationshinweise Z501J / Z501K Adapter IrDa USB Installation hints Z501J / Z501K Adapter IrDa USB Installationshinweise Z501J / Z501K Adapter IrDa USB Installation hints Z501J / Z501K Adapter IrDa USB 1/3.04 (Diese Anleitung ist für die CD geschrieben. Wenn Sie den Treiber vom WEB laden, entpacken


Selbstlernmodul bearbeitet von: begonnen: Inhaltsverzeichnis:

Selbstlernmodul bearbeitet von: begonnen: Inhaltsverzeichnis: bearbeitet von: begonnen: Fach: Englisch Thema: The Future Deckblatt des Moduls 1 ''You will have to pay some money soon. That makes 4, please.'' ''Oh!'' Inhaltsverzeichnis: Inhalt bearbeitet am 2 Lerntagebuch


Parameter-Updatesoftware PF-12 Plus

Parameter-Updatesoftware PF-12 Plus Parameter-Updatesoftware PF-12 Plus Mai / May 2015 Inhalt 1. Durchführung des Parameter-Updates... 2 2. Kontakt... 6 Content 1. Performance of the parameter-update... 4 2. Contact... 6 1. Durchführung



XV1100K(C)/XV1100SK(C) Wlan Telefon Aastra 312w XV1100K(C)/XV1100SK(C) All rights reserverd. Any reprinting or unauthorized use wihout the written permission of Wlan Telefon Aastra 312w Corporation, is expressly prohibited.





Dr. R. Guderlei exxcellent solutions gmbh Tim Felgentreff HPI. Versionsmanagement. Zentral oder Verteilt?

Dr. R. Guderlei exxcellent solutions gmbh Tim Felgentreff HPI. Versionsmanagement. Zentral oder Verteilt? Dr. R. Guderlei exxcellent solutions gmbh Tim Felgentreff HPI Versionsmanagement Zentral oder Verteilt? Agenda Verteilte Versionsverwaltung mit Git Git in der Praxis Fazit Grundlegendes Verteilung: kein





The English Tenses Die englischen Zeitformen

The English Tenses Die englischen Zeitformen The English Tenses Die englischen Zeitformen Simple Present (Präsens einfache Gegenwart) Handlungen in der Gegenwart die sich regelmäßig wiederholen oder einmalig geschehen I go you go he goes she goes



XV1100K(C)/XV1100SK(C) Cobra Terminal Server Zugriff XV1100K(C)/XV1100SK(C) All rights reserverd. Any reprinting or unauthorized use wihout the written permission of Cobra Terminal Server Zugriff Corporation, is expressly prohibited.


Getting started with MillPlus IT V530 Winshape

Getting started with MillPlus IT V530 Winshape Getting started with MillPlus IT V530 Winshape Table of contents: Deutsche Bedienungshinweise zur MillPlus IT V530 Programmierplatz... 3 English user directions to the MillPlus IT V530 Programming Station...


TVHD800x0. Port-Weiterleitung. Version 1.1

TVHD800x0. Port-Weiterleitung. Version 1.1 TVHD800x0 Port-Weiterleitung Version 1.1 Inhalt: 1. Übersicht der Ports 2. Ein- / Umstellung der Ports 3. Sonstige Hinweise Haftungsausschluss Diese Bedienungsanleitung wurde mit größter Sorgfalt erstellt.


Prediction Market, 28th July 2012 Information and Instructions. Prognosemärkte Lehrstuhl für Betriebswirtschaftslehre insbes.

Prediction Market, 28th July 2012 Information and Instructions. Prognosemärkte Lehrstuhl für Betriebswirtschaftslehre insbes. Prediction Market, 28th July 2012 Information and Instructions S. 1 Welcome, and thanks for your participation Sensational prices are waiting for you 1000 Euro in amazon vouchers: The winner has the chance


Moodle aktuell halten mit Git

Moodle aktuell halten mit Git Moodle aktuell halten mit Git 3a 1 2 3b 3c 4c Vorstellung Andreas Grabs Softwareentwickler Seit 2010 Moodle Core- Entwickler Freier Mitarbeiter eledia GmbH Inhalt Allgemeines Allgmeine Vorteile Vorteile


Introducing PAThWay. Structured and methodical performance engineering. Isaías A. Comprés Ureña Ventsislav Petkov Michael Firbach Michael Gerndt

Introducing PAThWay. Structured and methodical performance engineering. Isaías A. Comprés Ureña Ventsislav Petkov Michael Firbach Michael Gerndt Introducing PAThWay Structured and methodical performance engineering Isaías A. Comprés Ureña Ventsislav Petkov Michael Firbach Michael Gerndt Technical University of Munich Overview Tuning Challenges


Effizienz im Vor-Ort-Service

Effizienz im Vor-Ort-Service Installation: Anleitung SatWork Integrierte Auftragsabwicklung & -Disposition Februar 2012 Disposition & Auftragsabwicklung Effizienz im Vor-Ort-Service Disclaimer Vertraulichkeit Der Inhalt dieses Dokuments


Benutzer- und Referenzhandbuch

Benutzer- und Referenzhandbuch Benutzer- und Referenzhandbuch MobileTogether Client User & Reference Manual All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, or mechanical,


eclipse - EGit HowTo

eclipse - EGit HowTo eclipse - EGit HowTo An der HSR steht den Studierenden ein git Server für die Versionskontrolle zur Verfügung. Dieses HowTo fasst die notwendigen Informationen zur Verwendung dieses Dienstes in Verwendung


Die Projek*ools. Files, Git, Tickets & Time

Die Projek*ools. Files, Git, Tickets & Time Die Projek*ools Files, Git, Tickets & Time Agenda Die Abgabe von Dokumenten: Files Das Pflegen von Software: Versionskontrolle mit Git Management von Anforderungen: Tickets Management von Zeit: Time Files


Contents. Interaction Flow / Process Flow. Structure Maps. Reference Zone. Wireframes / Mock-Up

Contents. Interaction Flow / Process Flow. Structure Maps. Reference Zone. Wireframes / Mock-Up Contents 5d 5e 5f 5g Interaction Flow / Process Flow Structure Maps Reference Zone Wireframes / Mock-Up 5d Interaction Flow (Frontend, sichtbar) / Process Flow (Backend, nicht sichtbar) Flow Chart: A Flowchart


USB-Stick (USB-Stick größer 4G. Es ist eine größere Partition notwendig als die eines 4GB Rohlings, der mit NTFS formatiert wurde)

USB-Stick (USB-Stick größer 4G. Es ist eine größere Partition notwendig als die eines 4GB Rohlings, der mit NTFS formatiert wurde) Colorfly i106 Q1 System-Installations-Tutorial Hinweise vor der Installation / Hit for preparation: 准 备 事 项 : 外 接 键 盘 ( 配 套 的 磁 吸 式 键 盘 USB 键 盘 通 过 OTG 插 发 射 器 的 无 线 键 盘 都 可 ); U 盘 ( 大 于 4G 的 空 白 U 盘,


How-To-Do. Hardware Configuration of the CC03 via SIMATIC Manager from Siemens

How-To-Do. Hardware Configuration of the CC03 via SIMATIC Manager from Siemens How-To-Do Hardware Configuration of the CC03 via SIMATIC Manager from Siemens Content Hardware Configuration of the CC03 via SIMATIC Manager from Siemens... 1 1 General... 2 1.1 Information... 2 1.2 Reference...