Git

1 - About

http://git-scm.com/about/ and book.

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:

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

3 - 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 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
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

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

7 - Documentation / Reference

code/version/git/start.txt · Last modified: 2018/12/07 10:15 by gerardnico