Table Of Contents
Table of Contents
The Story behind the Succinctly Series of Books
Introduction
Chapter 1 Overview
Chapter 2 Getting Started
Chapter 3 Recording Changes
Chapter 4 Undoing Changes
Chapter 5 Branches
Chapter 6 Remote Repositories
Conclusion
Detailed Table of Contents
Introduction
Introduction
Git is an open-source version control system known for its speed, stability, and distributed collaboration model. Originally created in 2006 to manage the entire Linux kernel, Git now boasts a comprehensive feature set, an active development team, and several free hosting communities.
Git was designed from the ground up, paying little attention to the existing standards of centralized versioning systems. So, if you’re coming from an SVN or CVS background, try to forget everything you know about version control before reading this guide.
Distributed software development is fundamentally different from centralized version control systems. Instead of storing file information in a single central repository, Git gives every developer a full copy of the repository. To facilitate collaboration, Git lets each of these repositories share changes with any other repository.
Figure 1: Distributed software development
Having a complete repository on your local machine has a far-reaching impact on the development cycle…
Faster Commands
First, a local copy of the repository means that almost all version control actions are much faster. Instead of communicating with the central server over a network connection, Git actions are performed on the local machine. This also means you can work offline without changing your workflow.
Stability
Since each collaborator essentially has a backup of the whole project, the risk of a server crash, a corrupted repository, or any other type of data loss is much lower than that of centralized systems that rely on a single point-of-access.
Isolated Environments
Every copy of a Git repository, whether local or remote, retains the full history of a project. Having a complete, isolated development environment gives each user the freedom to experiment with new additions before polishing them up into clean, publishable commits.
Efficient Merging
A complete history for each developer also means a divergent history for each developer. As soon as you make a single local commit, you’re out of sync with everyone else on the project. To cope with this massive amount of branching, Git became very good at merging divergent lines of development.
Chapter 1 Overview
Chapter 1 Overview
Each Git repository contains 4 components:
- The working directory
- The staging area
- Committed history
- Development branches
Everything from recording commits to distributed collaboration revolves around these core objects.
The Working Directory
The Working Directory
The working directory is where you actually edit files, compile code, and otherwise develop your project. For all intents and purposes, you can treat the working directory as a normal folder. Except, you now have access to all sorts of commands that can record, alter, and transfer the contents of that folder.
Figure 2: The working directory
The Staging Area
The Staging Area
The staging area is an intermediary between the working directory and the project history. Instead of forcing you to commit all of your changes at once, Git lets you group them into related changesets. Staged changes are not yet part of the project history.
Figure 3: The working directory and the staging area
Committed History
Committed History
Once you’ve configured your changes in the staging area, you can commit it to the project history where it will remain as a “safe” revision. Commits are “safe” in the sense that Git will never change them on its own, although it is possible for you to manually rewrite project history.
Figure 4: The working directory, staged snapshot, and committed history
Development Branches
Development Branches
So far, we’re still only able to create a linear project history, adding one commit on top of another. Branches make it possible to develop multiple unrelated features in parallel by forking the project history.
Figure 5: The complete Git workflow with a branched history
Git branches are not like the branches of centralized version control systems. They are cheap to make, simple to merge, and easy to share, so Git-based developers use branches for everything—from long-running features with several contributors to 5-minute fixes. Many developers only work in dedicated topic branches, leaving the main history branch for public releases.
Chapter 2 Getting Started
Chapter 2 Getting Started
Installation
Git is available on all major platforms. The instructions below will walk you through installation on Windows, but it’s always best to consult the official Git Web site for the most up-to-date information.
Git for Windows is available through the MsysGit package.
- Download and execute the most recent version of the installer.
- In the setup screen titled “Adjusting your PATH environment,” select the option “Use Git Bash only.”
- In the setup screen titled “Choosing the SSH executable,” select “Use OpenSSH.”
- Finally, select “Checkout Windows-style, commit Unix-style line endings” and press “Next” to begin the installation.
This will install a new program called “Git Bash,” which is the command prompt you should use whenever you’re working with Git.
Figure 6: Screenshot of Git Bash
Configuration
Configuration
Git comes with a long list
Impressum
Verlag: BookRix GmbH & Co. KG
Tag der Veröffentlichung: 06.02.2016
ISBN: 978-3-7396-3606-1
Alle Rechte vorbehalten