# gitploy

Outillage git minimal pour fluidifier un déploiement *rolling release* :
une branche de développement, des branches d'environnement, et deux
sous-commandes git **transactionnelles** et **sûres**.

```bash
git deploy <remote> <branche> -m "message"   # livrer le dev vers un environnement
git hotfix <remote> <branche> -m "message"   # corriger un environnement puis rapatrier dans le dev
```

## Modèle de branches

- Une **branche de dev** (par défaut `master`) : là où tu travailles et intègres.
- Des **branches de déploiement** (`prod`, `stage`, …) : une par environnement.
- Tout passe par un remote (ex. `gitea`) qui déclenche le déploiement serveur.

`git deploy` fait avancer une branche d'environnement au niveau du dev (merge).
`git hotfix` permet de corriger un environnement **sans changer de branche à la
main**, puis rapatrie automatiquement le correctif dans le dev.

## Installation

### En submodule (recommandé)

```bash
# dans le dépôt qui doit déployer
git submodule add https://figureslibres.io/gitea/bachir/gitploy.git gitploy
git submodule update --init
gitploy/setup
```

### En dépôt autonome

```bash
git clone gitea-figureslibres.io:bachir/gitploy.git
cd gitploy && ./setup    # configure le dépôt parent courant
```

`setup` installe des **alias git locaux** (`git deploy`, `git hotfix`) pointant
vers les scripts — **aucune modification du `PATH`**. git n'exécutant jamais une
config versionnée tout seul (par sécurité), cette étape unique est nécessaire.

## Configuration

Stockée dans `git config` (aucun fichier `.env`) :

| Clé | Défaut | Rôle |
|-----|--------|------|
| `deploy.source` | `master` | Branche de développement |
| `deploy.push`   | `false`  | Autorise le push réel (sinon simulation locale) |

```bash
git config deploy.source master
git config deploy.push true      # activer le push réel quand tu es prêt
```

Tant que `deploy.push` est `false`, **rien n'est poussé** : tu peux tout tester
en local, les scripts affichent le push qu'ils auraient fait.

## Utilisation

### Déployer le dev vers un environnement

```bash
# tu es sur master
git deploy gitea prod -m "ajout du bloc contact"
```

1. commit sur `master` (message obligatoire s'il y a des modifs) ;
2. merge `master` → `prod` ;
3. push atomique (dernière étape) ;
4. retour sur `master`.

### Corriger un environnement (hotfix)

```bash
# tu es sur master, tu écris le correctif (sans committer)
git hotfix gitea prod -m "fix: lien du menu"
```

1. met tes modifs de côté (stash) ;
2. bascule sur `prod`, applique et committe le correctif ;
3. rapatrie le correctif dans `master` (merge) ;
4. push atomique puis retour sur `master`.

Résultat : le correctif est sur `prod` **et** sur `master`, sans embarquer les
features non livrées de `master`.

## Sûreté

- **Confirmation** : un `git status` + le plan d'action, avec validation `[O/n]`.
- **Transactionnel** : toutes les mutations locales d'abord ; en cas d'échec
  (conflit, etc.), l'arbre est **restauré à l'identique** (refs, branche
  courante, modifs en cours) et **rien n'est poussé**.
- **Push en dernier**, **atomique** (`--atomic`, tout ou rien), **jamais forcé**,
  précédé d'un `--dry-run`.
- **Garde-fous** : remote et branche existants, cible ≠ branche de dev, bonne
  branche de départ, aucun merge/rebase en cours.

## Complétion (optionnelle)

Complète le remote puis la branche, lus en direct depuis le dépôt :

```bash
# dans ~/.bashrc
source /chemin/vers/gitploy/deploy-completion.bash
```

## Fichiers

| Fichier | Rôle |
|---------|------|
| `git-deploy` | Sous-commande `git deploy` |
| `git-hotfix` | Sous-commande `git hotfix` |
| `_deploy_lib.sh` | Helpers partagés (config, garde-fous, confirmation) |
| `deploy-completion.bash` | Complétion bash |
| `setup` | Installe les alias git (sans PATH) |