Git
About
Git is a content-addressable file system 1) used to track directory tree content (as defined by its creator Linux Torvald)
The tracking happens with commit that creates a snapshot of the directory tree. The commit identifier are just a hash value (digest) (Meaning that no files are copied).
The core of Git is a database key-value data store. When you insert any kind of content into a Git repository, Git will hand you back a unique key that you can use later to retrieve that content.
It's then really cheap to create branch and supports then non-linear development (thousands of parallel branches)
It's not a version control system but is used this way most of the time.
Git 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 whole history.
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
File State
Git has three main file states:
| States | Description |
|---|---|
| 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 |
Directory
Three main sections of a Git project:
| Areas | File State | Description |
|---|---|---|
| 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 (Head Branch | Branch Head) / Last commit ?? | Commited | Store the metadata and object database for a project. (This is what is copied when a repository is cloned from another computer.) |
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.
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 Order | Command | Description |
|---|---|---|
| 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 |
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.
Action
Pages
Static website hosting