Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • S stuart
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 2
    • Issues 2
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • mouselab
  • stuart
  • Wiki
  • Git commands

Git commands · Changes

Page history
Create Git commands authored Jun 11, 2021 by Elise  JACQUEMET's avatar Elise JACQUEMET
Hide whitespace changes
Inline Side-by-side
Git-commands.md 0 → 100644
View page @ 86d23c9d
## Sommaire <a name="sommaire"></a>
- [Configuration Git](#config)
- [Workflow Git](#workflow)
- [Nouvelle feature](#new-feature)
- [Correction de bug](#bugfix)
- [Correction critique sur master](#hotfix)
- [Déploiement nouvelle version](#MAJ)
<a name="config"></a>
## Configuration Git
Configuration obligatoire du `~/.gitconfig` :
```ini
[user]
name = Prénom Nom
email = prenom.nom@pasteur.fr
[branch]
autosetuprebase = always
```
Alias utiles :
```ini
[alias]
co = checkout
st = status
ci = commit
br = branch
ds = diff --staged
unstage = reset HEAD --
amend = commit --amend --no-edit
lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=iso --branches --tags --remotes
```
[:arrow_up:](#sommaire)
<a name="workflow"></a>
## Workflow Git
Le workflow se base sur [Git Flow](http://nvie.com/posts/a-successful-git-branching-model/) dans les grandes lignes. La branche `develop` contient les développements de la prochaine version, et `master` représente la version déployée sur le server Shinypro.
<a name="new-feature"></a>
#### Développement d'une nouvelle feature :
A faire sur develop !
```bash
$ git checkout develop
$ git checkout -b feature/ma-nouvelle-feature
... réaliser les développements
$ git commit -a
$ git push -u origin feature/ma-nouvelle-feature
```
Créer la Merge Request (banche feature/ma-nouvelle-feature -> develop dans GitLab. Référencer l'issue concernée dans le message de merge (en écrivant *issue #num-de-l'issue*)
[:arrow_up:](#sommaire)
<a name="bugfix"></a>
#### Correction de bug lié à une issue :
A faire sur develop !
```bash
$ git checkout develop
$ git checkout -b bugfix/mon-bugfix
... réaliser les développements
$ git commit -a
$ git push -u origin bugfix/mon-bugfix
```
Créer la Merge Request (banche bugfix/mon-bugfix -> develop dans GitLab. Référencer l'issue concernée dans le message de merge (en écrivant *issue #num-de-l'issue*)
[:arrow_up:](#sommaire)
<a name="hotfix"></a>
#### Hotfix :
Utilisé pour corriger rapidemment uetne erreur directement sur master, sans passer par develop.
```bash
$ git checkout master
$ git checkout -b hotfix/mon-hotfix
... réaliser les développements
$ git commit -a
$ git push -u origin hotfix/mon-hotfix
```
Créer la Merge Request associée dans GitLab. Une fois la branche mergée dans `master` il est possible de `cherry-pick` les commits sur `develop` par exemple :
```bash
$ git checkout develop
$ git cherry-pick identifiantducommit1
$ git cherry-pick identifiantducommit2
$ git push
```
[:arrow_up:](#sommaire)
<a name="MAJ"></a>
#### MAJ de master sur une nouvelle version (à déployer sur le server) :
Commencer par créer un tag sur **develop** lorsqu'une version satisfaisante pourrait être déployée
```bash
$ git checkout develop # (1)
$ git merge master # pour être sûrs que develop dispose de tous les commits de master (2)
# doit renvoyer "already up to date". Sinon, un commit de merge sera ajouté, avec de potentiels conflits.
$ git tag # pour voir les tags existants
$ git tag -a vx.x -m "stuart version x.x"
$ git push origin develop --tags # (3)
```
Une fois que le déploiement est validé, on met à jour master sur le tag créé
```bash
$ git checkout master # on retourne sur master
$ git merge --ff-only vx.x # on remonte master au niveau du tag en fast-forward (4)
$ git push origin develop master --tags
```
```
(1)
master o o develop
| |
o o
\ /
o
|
(2)
o develop
/ |
/ |
master o o
| |
o o
\ /
o
|
(3)
o develop
|
o vx.x
|
o
/ |
/ |
master o o
| |
o o
\ /
o
|
(4)
o develop
|
master o vx.x
|
o
/ |
/ |
o o
| |
o o
\ /
o
|
```
**NB :** les tests doivent être faits après l'étape `(2)`, une fois que `develop` dispose de tous les commits de `master`.
Si une branche de hotfix doit être créée à partir de `master` créer la branche de hotfix à partir de ce point.
**Impotant :**
- Toujours vérifier l'état di repository local avec `git lg` avant de les push sur le dépot distant.
- Une fois une Merge Request est mergée sur gitlab, vérifier le graph en ligne avant de pull les mises à jour en local : en cas d'erreur de merge, on peut forcer un pushde la version local sur le repository distant pour "annuler" le merger (en cas d'erreur dans le choix des branches par ex)
[:arrow_up:](#sommaire)
[Go back to Home page](Home)
\ No newline at end of file
Clone repository
  • Git commands
  • Home