Description: ce document contient des instructions git en ligne de commande pour un travail collaboratif sur un dépôt commun, après avoir créé un dépôt distant, et après avoir générer le dépôt sur la machine locale et établit le pont entre les deux. Il est possible de reproduire les principes décrits, sans ligne de commande, en utilisant uniquement l'interface utilisateur web des services GIT distants (ithub, Gitlab, Gitea, Bitbucket, …). Il existe aussi d'autres façon d'utiliser GIT de façon collaborative.
Contexte: Un dépôt GIT distant commun est créé. Des personnes contribuent à plusieurs sur ce dépôt distant, en faisant des modifications sur leurs machines locales, et en établissant des ponts avec le dépôt distant, en ligne de commande.
Pré-requis:
Nota: la branche “develop” peut avoir un autre nom, celui que vous voulez. Dans ce cas, il faut adapter tout ce qui suit avec cet autre nom.
“`NOM-CATEGORIE-DE-LA-BRANCHE`” en majuscule dont les mots sont séparés par des tirets du 6 (“`-`”), suivi du séparateur “`/`”, suivi du “`Nom-De-La-Branche`” en minuscule dont les mots sont séparés par des tirets du 6 (“`-`”).
Rappel: l'enchaînement des commandes GIT ci-dessous, s'envisage lorsqu'un dépôt distant est ouvert, qu'il a été configuré de ses deux branches éternelles, et que plusieurs personnes effectuent un travail collaboratif via ce dépôt GIT distant à partir de leurs machines locales.
```
git checkout master git pull origin master git status git checkout develop git pull origin develop git status
```
Prendre connaissance de la convention des noms des branches (ci-dessus). Puis:
```
git checkout develop git branch -a git branch PROPOSITION/Nom-De-La-Proposition git checkout PROPOSITION/Nom-De-La-Proposition git push -u origin PROPOSITION/Nom-De-La-Proposition
```
Produisez vos contenus, ajoutez, supprimez, modifiez, etc …
```
git checkout PROPOSITION/Nom-De-La-Proposition git add -A . git commit -m "commentaire descriptif"
```
Attention: bien écrire la commande rebase en plaçant un “/” devant la branche concernée par le rembobinage. Sinon, vous aurez des erreurs. ```
git checkout PROPOSITION/Nom-De-La-Proposition git fetch origin git rebase origin/master git rebase origin/develop git rebase origin/PROPOSITION/Nom-De-La-Proposition
``` Si conflits, résolvez !
Plus c'est partagé tôt, mieux c'est ! Cela permet aux autres de savoir ce que vous faites. Cela peut leur donner des idées d'améliorations à partager avec vous.
```
git checkout PROPOSITION/Nom-De-La-Proposition git push -u origin PROPOSITION/Nom-De-La-Proposition
```
Répétez les étapes du workflow de production de votre proposition, autant de fois que vous le souhaitez, tout au long de la progression de vos travaux de production.
Attention: bien écrire la commande rebase en plaçant un “/” devant la branche concernée par le rembobinage. Sinon, vous aurez des erreurs. ```
git checkout PROPOSITION/Nom-De-La-Proposition git fetch origin git rebase origin/master git rebase origin/develop git rebase origin/PROPOSITION/Nom-De-La-Proposition
``` Si conflits, résolvez !
```
git checkout PROPOSITION/Nom-De-La-Proposition git push -o merge_request.create -o merge_request.target=PROPOSITION/Nom-De-La-Proposition
```
S'il vous est demandé de faire des modifications, re-travaillez votre proposition, effectuez les éventuelles modifications demandées, recommencez les étapes relatives à la production de la proposition, puis rembobinez, puis redemandez une autorisation de fusionner votre branche dans `develop`. Recommencez ces opérations tant que l'autorisation de fusion n'est pas obtenue. Une fois que tout va bien, passez à l'étape d'après.
une fois l'autorisation de fusion obtenue
A T T E N T I O N - D A N G E R !!!
Ne faites pas ce qui suit si vous avez l'intention de revenir sur votre branche pour continuer des travaux. Si vous voulez continuer à travailler sur votre branche, continuez à répéter les instructions précédentes. Sinon, vous allez au devant de grandes difficultés !!!
```
git checkout PROPOSITION/Nom-De-La-Proposition git rebase -i develop git checkout develop git pull origin develop git merge --no-ff PROPOSITION/Nom-De-La-Proposition git push origin develop git branch -d PROPOSITION/Nom-De-La-Proposition git push origin --delete PROPOSITION/Nom-De-La-Proposition
```
Informez-vous sur la convention de numéros des versions - voir début de document.
Puis, regardez dans la liste des versions existantes: ```
git checkout develop git tag
``` Décidez d'un nouveau numéro de version, arrivant à la suite des précédents selon la liste [NumVersion].
```
git checkout develop git log --abbrev-commit
``` Décidez du numéro de commit sur lequel versionner [NumCommit]
```
git checkout develop git branch VERSIONNAGE/NumVersion NumCommit git checkout VERSIONNAGE/NumVersion git tag NumVersion git checkout develop git merge VERSIONNAGE/NumVersion git push --tags origin develop git branch -d VERSIONNAGE/NumVersion git checkout master git merge --f-only NumVersion
```
Utilisez ces instructions de “correctifs”, uniquement pour appliquer des correctifs rapides à une version publiée (notion de rustine, de patch, de hot-fix). Si vous envisagez de produire d'importantes modifications, alors ce ne sont pas des correctifs, mains plutôt de nouveaux travaux de production d'une nouvelle version. Dans ce cas, il vous faut vous référer aux sections précédentes.
Repérez le numéro de la version sur laquelle vous allez opérer un correctif: ```
git checkout master git tag
``` Le numéro de correctif [NumCorrectif], que vous allez appliquer, est le numéro de version à corriger augmenté d'un cran supérieur (exemple: 2.1.0 → 2.1.1; 0.1.pre-alpha.1 → 0.1.pre-alpha.2)
```
git branch CORRECTIF/NumCorrectif master git checkout CORRECTIF/NumCorrectif
```
```
git checkout CORRECTIF/NumCorrectif git tag NumCorrectif git checkout develop git merge CORRECTIF/NumCorrectif git push --tags origin develop git branch -d CORRECTIF/NumCorrectif git checkout master git merge --ff-only NumCorrectif
```