Taille: 2045
Commentaire:
|
Taille: 4424
Commentaire:
|
Texte supprimé. | Texte ajouté. |
Ligne 15: | Ligne 15: |
* Pourquoi versionner? * historique : voir versions passées * expérimentation : explorer une nouvelle version possible * travail collaboratif : travail sur versions en parallèle (en local, sur branches...) puis fusion des versions |
|
Ligne 24: | Ligne 28: |
* .gitignore : suivre le modèle * git init * git status * git add |
* créer un répertoire en local et s'y déplacer {{{ mkdir atelier cd atelier }}} * initialiser un dépôt vierge {{{ git init }}} * .git créé = tout le dépôt en local * vérifier l'état du dépôt {{{ git status }}} * créer du contenu (un répertoire et un fichier) sous {{{atelier}}} * créer le fichier caché commandant à git d'ignorer certains fichiers ou répertoires * {{{.gitignore}}} : suivre le modèle * ajouter les fichiers et répertoires à l'index de git {{{ git add . }}} |
Ligne 29: | Ligne 50: |
* git commit * gitk |
* engager ses changements {{{ git commit -a -m "message de commit" }}} * vérifier le journal des commits {{{ git log }}} * vérifier l'historique des versions (commits) {{{ gitk }}} == INTERFACE WEB DU SERVEUR == * projets * shortlog * liste de commits * tag master = head master * commit * hash identifiant commit et son parent * diff, blob, (blame), history (+ diff to current) * commitdiff * tree : l'arborescence des sources (web) * snapshot : les sources (téléchargement) * heads (= branches) |
Ligne 34: | Ligne 79: |
* Initialiser un dépôt git * git config * git push * Récupérer localement un dépôt git existant sur serveur (pas encore récupéré) * git clone * git config |
* Initialiser un dépôt git sur le serveur ('''pas fait dans l'atelier''') * configurer en local l'URL où sera le dépôt sur serveur {{{ git config remote.origin.url ssh://gitosis@git.auf/atelier }}} * pousser sur le serveur son code local {{{ git push origin master }}} * Récupérer localement un dépôt git existant sur serveur (qui n'a pas encore été récupéré) {{{ git clone ssh://gitosis@git.auf/espace-formation }}} |
Ligne 43: | Ligne 95: |
* Éditer l'arboresence du projet * git status * git add * git rm * git commit * git pull * git push |
* vérifier l'état du dépôt local {{{ git status }}} * tirer en local la dernière version du serveur {{{ git pull }}} * éditer l'arborescence du projet * au besoin, ajouter les fichiers et répertoires à l'index de git {{{ git add . }}} * au besoin, supprimer des fichiers ou répertoires de l'index de git {{{ git rm nom_fichier }}} * engager ses changements {{{ git commit -a -m "message significatif de commit" }}} * s'assurer d'avoir la dernière version avant de pousser {{{ git pull }}} * pousser sa nouvelle version locale sur le serveur {{{ git push }}} |
Ligne 54: | Ligne 128: |
* git fetch | |
Ligne 56: | Ligne 129: |
* créer en local à partir du serveur * git branch -t |
|
Ligne 90: | Ligne 165: |
* Aller plus loin : * Participer aux projets * de l'AUF : [[http://git.auf.org|Dépôt AUF]] * d'autres projets Open source : [[https://github.com/|GitHub]] * Explorer au besoin le [[http://git-scm.com/documentation|Site officiel]], notamment sa [[http://git-scm.com/documentation|documentation]] ---- |
Git : versionner ses sources
Sommaire
INTRODUCTION
- Objectifs :
- connaître les commandes de base pour participer à un projet AUF
- Environnement technique :
- git-core
- gitk
- Pourquoi versionner?
- historique : voir versions passées
- expérimentation : explorer une nouvelle version possible
- travail collaboratif : travail sur versions en parallèle (en local, sur branches...) puis fusion des versions
- Pourquoi Git?
- nouvelle génération
- distribué (local, hors-ligne)
VERSIONNER EN LOCAL
- Initialiser un dépôt git
- créer un répertoire en local et s'y déplacer
mkdir atelier cd atelier
- initialiser un dépôt vierge
git init
- .git créé = tout le dépôt en local
- vérifier l'état du dépôt
git status
créer du contenu (un répertoire et un fichier) sous atelier
- créer le fichier caché commandant à git d'ignorer certains fichiers ou répertoires
.gitignore : suivre le modèle
- ajouter les fichiers et répertoires à l'index de git
git add .
- créer un répertoire en local et s'y déplacer
- Amorcer le suivi
- engager ses changements
git commit -a -m "message de commit"
- vérifier le journal des commits
git log
- vérifier l'historique des versions (commits)
gitk
- engager ses changements
INTERFACE WEB DU SERVEUR
- projets
- shortlog
- liste de commits
- tag master = head master
- commit
- hash identifiant commit et son parent
- diff, blob, (blame), history (+ diff to current)
- commitdiff
- tree : l'arborescence des sources (web)
- snapshot : les sources (téléchargement)
- heads (= branches)
VERSIONNER SUR SERVEUR
Initialiser un dépôt git sur le serveur (pas fait dans l'atelier)
- configurer en local l'URL où sera le dépôt sur serveur
git config remote.origin.url ssh://gitosis@git.auf/atelier
- pousser sur le serveur son code local
git push origin master
- configurer en local l'URL où sera le dépôt sur serveur
- Récupérer localement un dépôt git existant sur serveur (qui n'a pas encore été récupéré)
git clone ssh://gitosis@git.auf/espace-formation
PROCESSUS DE VERSIONNAGE
- vérifier l'état du dépôt local
git status
- tirer en local la dernière version du serveur
git pull
- éditer l'arborescence du projet
- au besoin, ajouter les fichiers et répertoires à l'index de git
git add .
- au besoin, supprimer des fichiers ou répertoires de l'index de git
git rm nom_fichier
- engager ses changements
git commit -a -m "message significatif de commit"
- s'assurer d'avoir la dernière version avant de pousser
git pull
- pousser sa nouvelle version locale sur le serveur
git push
BRANCHES
- Créer en local
- git branch
- créer en local à partir du serveur
- git branch -t
- Créer sur serveur
- git push
- Changer de branche
- git checkout
- Fusionner les branches
- git merge
- Conflits
- Supprimer en local
- git branch
- Supprimer sur serveur
- git push
WORKFLOW DE DÉVELOPPEMENT
- Développement (branch dev, environnement DEV)
- développement dans environnement DEV (local)
branche dev : code stable développé
- validation informatique du release
- Tests (branch test, environnement TEST)
- merge de branche dev dans la branch test
branche test : code stable à tester par responsables métier
- déploiement dans environnement de TEST (serveur, identique à PROD)
- validation métier du release
- Production (branch master, environnement PROD)
- merge de branch test dans la branch master
branch master : code stable validé
- déploiement dans environnement de PROD
- utilisation par utilisateurs finaux
CONCLUSION
- Tout projet doit être versionné sur le dépôt central (privé ou public)
- Aller plus loin :
- Participer aux projets
Explorer au besoin le Site officiel, notamment sa documentation