Table of Contents
1 - About
The Git feature that really makes it stand apart from nearly every other SCM out there is its branching model. It has a Strong support for non-linear development (thousands of parallel branches)
Git included is distributed. Then instead of doing a “checkout” of the current tip of the source code, you do a clone of the entire repository. Every user essentially has a full backup of the main server.
Git store information as a set of snapshots of a miniature filesystem (and can then be considered as a mini filesystem with some incredibly powerful tools built on top of it)
Nearly Every Operation Is Local (no network latency as with CVCS). Because you have the entire history of the project right there on your local disk, most operations seem almost instantaneous. 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.
Data Integrity: Everything in Git is check-summed with SHA-1 hash before it is stored and is then referred to by that checksum.
Git Generally Only Adds Data: Nearly all actions in Git add data to the Git database.
Setting up an environment: Git - Getting Started
2 - File State
Git has three main file states:
|Committed||The data is safely stored in the local database (The Git directory)|
|Modified||A modified file has not been committed to the local database yet|
|Staged||A modified file was marked in its current version to go into the next commit snapshot|
3 - Directory
Three main sections of a Git project:
|Working directory||Modified||A single checkout of one version of the project (These files are pulled out of the Git directory and placed on disk to use or modify.)|
|Staging area (or index)||Modified and staged||Stores information and information that will go into the next commit|
| Git directory - |
Git - Head Branch ??
|Commited||Store the metadata and object database for a project. (This is what is copied when a repository is cloned from another computer.)|
4 - Workflow
Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.
4.1 - Basic
The basic Git workflow:
- Files are modified in the working directory.
- They are then staged through snapshots into the staging area.
- When a commit occurs, it takes the files in the staging area and stores that snapshot permanently to the Git directory.
| Workflow |
|0|| git clone |
or git pull
| Get a complete git repository from a remote and create a working directory
Get the modifications (commits) from a remote
|1||git add||Add the modifications to the staging area (Ready to be committed)|
|2||git add||Create a commit from the modifications (a permanently snapshot is created)|
|3||git push||Push the modifications (commits) to a remote|
4.2 - Integration manager and lieutenants
Another common Git workflow involves an integration manager — a single person who commits to the 'blessed' repository. A number of developers then clone from that repository, push to their own independent repositories, and ask the integrator to pull in their changes.
For big project, the integration manager may got help of some people ('lieutenants') that are in charge of a specific subsystem of the project.
5 - Action
6 - Pages
Static website hosting