Licence

Licence

Introduction

Programme

Programme

  1. Contenu de la formation

  2. Source du contenu

Mon expérience

Mon expérience

Structure de la journée

Structure de la journée

Feedback

Feedback

Avertissement

Avertissement

Concepts et premières commandes

Gestion de Version

Principes

Historique

Generation Commentaire Exemples
0eme À l’Arrache cp -r data/ data.old/
1ere Modèle Local RCS (1982) - SCSS - …
2eme Modèle Centralisé CVS (1990) - SVN (2000) - …
3eme Modèle Distribué GIT (2005) - Mercurial - …

source : http://ericsink.com/vcbe/html/history_of_version_control.html

Modèle Local

Modèle Centralisé

Modèle Distribué

Démonstration du modèle décentralisé

cd /tmp
mkdir code
cd code
git init
echo "Hello World !" > README.txt
git add README.txt
git commit -m "first commit"
cd ~
git clone /tmp/code/
cd code
pwd

Git

Introduction

Sous-Programmes et Aide

Concepts

Contenu

Lieux

États

Exemple de cycle classique

Petit Lexique

Premières Commandes

git-config

git-init

git-add

git-commit

git-log

Marqueurs

double dot

git log master..experiment
git log experiment --not master
D
C
git log experiment..master
git log experiment --not master
F
E

triple dot

git log master...experiment
F
E
D
C

git-diff

git diff --staged

git-status

.gitignore

Branch - Checkout

git-branch

git-branch

cd depot

git checkout -b iss53

git commit

git checkout master && git checkout -b hotfix && git commit

git checkout master && git merge hotfix

git branch -D hotfix

git-checkout

git-checkout

git-stash

git-stash

git-reset

git-reset

git-reset soft

git-reset mixed

git-reset hard

git-reflog

git-reflog

git-revert

git-revert

git-tag

git-tag

Merge - Rebase

git-merge

git-merge

Précautions

Avant le merge

Après le merge

git checkout master
git merge iss53

Cas particulier

Options intéressantes

Conflits

git-cherry-pick

git cherry-pick

git-rebase

git-rebase

Clone - Fetch - Push - Pull

git-clone

git-clone

git-remote

git-remote

git-fetch

git-fetch

git-push

git-push

git-pull

git-pull

Workflow et Gitlab

Workflow

Workflow

Vision globale

Cycle général

Centralisé

Moyen Projet

Gros Projet

Gitlab

Présentation Générale

Utilisation

Comparaison à Github

Aller plus loin

Alias

Hooks

Submodule

Annexes

Gitlab Plugins

Gitlab CI

Gitlab API

Récapitulatif

Création

Création

git clone ssh://user@domain.tld/repo.git
git clone --recursive ssh://user@domain.tld/repo.git
git init

Changement locaux

Changement locaux

git status
git diff
git add .
git add -p <file>
git commit -a
git commit
git commit --amend

Historique des commits

Historique des commits

git log
git log -p <file>
git log --author=<committer name>

Note: <committer name> is a pattern, so Ed will match Edward Smith. Quotes are optional if the pattern doesn’t contain spaces.

git blame <file>
git stash
git stash pop

Branches & Tags

Branches & Tags

git branch
git checkout <branch>
git branch <new-branch>
git branch --track <new-branch> <remote-branch>
git branch -d <branch>
git push origin --delete <branch>
git tag <tag-name>

Mise à jour & Publication

Mise à jour & Publication

git remote -v
git remote show <remote>
git remote add <remote> <url>
git fetch <remote>
git fetch -p <remote>
git pull <remote> <branch>
git push <remote> <branch>
git remote add --track <remote-branch> <remote> <url>
git push --tags

Merge & Rebase

Merge & Rebase

git merge <branch>
git rebase <branch>

Note: You shouldn’t rebase published commits!

git rebase --abort
git rebase --continue
git mergetool
git add <resolved-file>
git rm <resolved-file>

Annuler

Annuler

git reset --hard HEAD
git checkout HEAD <file>
git revert <commit>
git checkout <commit> <file>
git reset --hard <commit>
git reset <commit>
git reset --keep <commit>

Glossaire

checkout

The action of updating all or part of the working tree with a tree object or blob from the object database, and updating the index and HEAD if the whole working tree has been pointed at a new branch.

commit

As a noun: A single point in the Git history; the entire history of a project is represented as a set of interrelated commits. The word “commit” is often used by Git in the same places other revision control systems use the words “revision” or “version”. Also used as a short hand for commit object.

As a verb: The action of storing a new snapshot of the project’s state in the Git history, by creating a new commit representing the current state of the index and advancing HEAD to point at the new commit.

evil merge

An evil merge is a merge that introduces changes that do not appear in any parent.

fast-forward

A fast-forward is a special type of merge where you have a revision and you are “merging” another branch’s changes that happen to be a descendant of what you have. In such these cases, you do not make a new mergecommit but instead just update to his revision. This will happen frequently on a remote-tracking branch of a remote repository.

merge

As a verb: To bring the contents of another branch (possibly from an external repository) into the current branch. In the case where the merged-in branch is from a different repository, this is done by first fetching the remote branch and then merging the result into the current branch. This combination of fetch and merge operations is called a pull. Merging is performed by an automatic process that identifies changes made since the branches diverged, and then applies all those changes together. In cases where changes conflict, manual intervention may be required to complete the merge.

As a noun: unless it is a fast-forward, a successful merge results in the creation of a new commit representing the result of the merge, and having as parents the tips of the merged branches. This commit is referred to as a “merge commit”, or sometimes just a “merge”.

origin

The default upstream repository. Most projects have at least one upstream project which they track. By default origin is used for that purpose. New upstream updates will be fetched into remote- tracking branches named origin/name-of-upstream-branch, which you can see using git branch -r.

push

Pushing a branch means to get the branch’s head ref from a remote repository, find out if it is a direct ancestor to the branch’s local head ref, and in that case, putting all objects, which are reachable from the local head ref, and which are missing from the remote repository, into the remote object database, and updating the remote head ref. If the remote head is not an ancestor to the local head, the push fails.

rebase

To reapply a series of changes from a branch to a different base, and reset the head of that branch to the result.

ref

A name that begins with refs/ (e.g. refs/heads/master) that points to an object name or another ref (the latter is called a symbolic ref). For convenience, a ref can sometimes be abbreviated when used as an argument to a Git command; see gitrevisions(7) for details. Refs are stored in the repository.

The ref namespace is hierarchical. Different subhierarchies are used for different purposes (e.g. the refs/heads/ hierarchy is used to represent local branches).

There are a few special-purpose refs that do not begin with refs/. The most notable example is HEAD

reflog

A reflog shows the local “history” of a ref. In other words, it can tell you what the 3rd last revision in this repository was, and what was the current state in this repository, yesterday 9:14pm.

remote-tracking branch

A ref that is used to follow changes from another repository. It typically looks like refs/remotes/foo/bar (indicating that it tracks a branch named bar in a remote named foo), and matches the right-hand-side of a configured fetch refspec. A remote-tracking branch should not contain direct modifications or have local commits made to it.

tag

A ref under refs/tags/ namespace that points to an object of an arbitrary type (typically a tag points to either a tag or a commit object). In contrast to a head, a tag is not updated by the commit command. A Git tag has nothing to do with a Lisp tag (which would be called an object type in Git’s context). A tag is most typically used to mark a particular point in the commit ancestry chain.

working tree

The tree of actual checked out files. The working tree normally contains the contents of the HEAD commit’s tree, plus any local changes that you have made but not yet committed.