feat: append of git standard management
This commit is contained in:
Infuseting
parent
613d7ea8f6
commit
b1efc2aec7
|
|
@ -1,165 +0,0 @@
|
||||||
---
|
|
||||||
name: frontend-design
|
|
||||||
description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
|
|
||||||
license: MIT
|
|
||||||
---
|
|
||||||
|
|
||||||
This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
|
|
||||||
|
|
||||||
The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.
|
|
||||||
|
|
||||||
## Design Thinking
|
|
||||||
|
|
||||||
Before coding, understand the context and commit to a BOLD aesthetic direction:
|
|
||||||
- **Purpose**: What problem does this interface solve? Who uses it?
|
|
||||||
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
|
|
||||||
- **Constraints**: Technical requirements (framework, performance, accessibility).
|
|
||||||
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
|
|
||||||
|
|
||||||
**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.
|
|
||||||
|
|
||||||
Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
|
|
||||||
- Production-grade and functional
|
|
||||||
- Visually striking and memorable
|
|
||||||
- Cohesive with a clear aesthetic point-of-view
|
|
||||||
- Meticulously refined in every detail
|
|
||||||
|
|
||||||
## Frontend Aesthetics Guidelines
|
|
||||||
|
|
||||||
Focus on:
|
|
||||||
- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
|
|
||||||
- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
|
|
||||||
- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
|
|
||||||
- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
|
|
||||||
- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.
|
|
||||||
|
|
||||||
NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.
|
|
||||||
|
|
||||||
Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.
|
|
||||||
|
|
||||||
**IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.
|
|
||||||
|
|
||||||
Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.
|
|
||||||
|
|
||||||
## Common Design Issues
|
|
||||||
|
|
||||||
### Typography Problems
|
|
||||||
**Issue**: Generic font choices (Inter, Arial, Roboto)
|
|
||||||
**Solution**: Use distinctive font pairings from Google Fonts or custom fonts. Examples: display fonts (Playfair Display, Bebas Neue, Archivo Black) paired with refined body fonts (Source Serif, Crimson Text, Work Sans).
|
|
||||||
|
|
||||||
**Issue**: Poor hierarchy and readability
|
|
||||||
**Solution**: Establish clear type scale with CSS variables. Use size, weight, and spacing to create visual hierarchy.
|
|
||||||
|
|
||||||
### Color & Theme Issues
|
|
||||||
**Issue**: Clichéd color schemes (purple gradients on white)
|
|
||||||
**Solution**: Commit to bold, contextual color choices. Use CSS variables for consistency. Consider: monochromatic with one accent, high-contrast brutalism, muted earth tones, vibrant complementary pairs.
|
|
||||||
|
|
||||||
**Issue**: Low contrast affecting accessibility
|
|
||||||
**Solution**: Verify color contrast ratios meet WCAG AA (4.5:1 for text, 3:1 for large text). Use tools like WebAIM Contrast Checker.
|
|
||||||
|
|
||||||
### Layout Issues
|
|
||||||
**Issue**: Predictable, cookie-cutter layouts
|
|
||||||
**Solution**: Experiment with asymmetry, overlapping elements, diagonal flow, grid-breaking components. Use CSS Grid and Flexbox creatively.
|
|
||||||
|
|
||||||
**Issue**: Responsive breakpoints failing
|
|
||||||
**Solution**: Test at 320px, 768px, 1024px, 1440px. Use fluid typography (clamp()) and container queries.
|
|
||||||
|
|
||||||
### Animation Issues
|
|
||||||
**Issue**: Excessive or jarring animations
|
|
||||||
**Solution**: Use subtle, purposeful animations. Respect `prefers-reduced-motion`. Focus on one well-orchestrated page load rather than scattered micro-interactions.
|
|
||||||
|
|
||||||
**Issue**: Performance problems from animations
|
|
||||||
**Solution**: Prefer CSS animations over JavaScript. Use `transform` and `opacity` (GPU-accelerated). Avoid animating `width`, `height`, `top`, `left`.
|
|
||||||
|
|
||||||
### Accessibility Violations
|
|
||||||
**Issue**: Missing keyboard navigation
|
|
||||||
**Solution**: Ensure all interactive elements are keyboard accessible. Add visible focus states.
|
|
||||||
|
|
||||||
**Issue**: Poor semantic HTML
|
|
||||||
**Solution**: Use semantic tags (`<nav>`, `<main>`, `<article>`, `<section>`). Add ARIA labels where needed.
|
|
||||||
|
|
||||||
**Issue**: Missing alt text on images
|
|
||||||
**Solution**: Add descriptive alt text for images. Use empty alt (`alt=""`) for decorative images.
|
|
||||||
|
|
||||||
## Design Validation Checklist
|
|
||||||
|
|
||||||
After creating a design, verify:
|
|
||||||
|
|
||||||
### Visual Quality
|
|
||||||
- [ ] Color contrast meets WCAG AA standards (4.5:1 for text)
|
|
||||||
- [ ] Typography is distinctive and readable
|
|
||||||
- [ ] Visual hierarchy is clear (headings, body, accents)
|
|
||||||
- [ ] Design has a clear aesthetic direction (not generic)
|
|
||||||
- [ ] Spacing and alignment are consistent
|
|
||||||
- [ ] No overused AI patterns (purple gradients, Inter font, etc.)
|
|
||||||
|
|
||||||
### Responsive Design
|
|
||||||
- [ ] Tested at mobile breakpoint (320px-480px)
|
|
||||||
- [ ] Tested at tablet breakpoint (768px-1024px)
|
|
||||||
- [ ] Tested at desktop breakpoint (1440px+)
|
|
||||||
- [ ] Text remains readable at all sizes
|
|
||||||
- [ ] Images and media scale appropriately
|
|
||||||
- [ ] No horizontal scrolling on small screens
|
|
||||||
|
|
||||||
### Accessibility
|
|
||||||
- [ ] All interactive elements keyboard accessible
|
|
||||||
- [ ] Focus states visible and clear
|
|
||||||
- [ ] Semantic HTML used throughout
|
|
||||||
- [ ] Alt text present for images
|
|
||||||
- [ ] Color is not the only indicator (for colorblind users)
|
|
||||||
- [ ] Animations respect `prefers-reduced-motion`
|
|
||||||
|
|
||||||
### Performance
|
|
||||||
- [ ] Animations use GPU-accelerated properties (`transform`, `opacity`)
|
|
||||||
- [ ] No layout thrashing from animations
|
|
||||||
- [ ] Images optimized (WebP, proper dimensions)
|
|
||||||
- [ ] Fonts loaded efficiently (font-display: swap)
|
|
||||||
- [ ] Critical CSS inlined for faster first paint
|
|
||||||
|
|
||||||
### Code Quality
|
|
||||||
- [ ] CSS variables used for theming consistency
|
|
||||||
- [ ] Clean, semantic class names
|
|
||||||
- [ ] No hardcoded magic numbers
|
|
||||||
- [ ] Comments explain complex decisions
|
|
||||||
- [ ] Works without JavaScript (progressive enhancement)
|
|
||||||
|
|
||||||
### Browser Compatibility
|
|
||||||
- [ ] Tested in Chrome/Edge (Chromium)
|
|
||||||
- [ ] Tested in Firefox
|
|
||||||
- [ ] Tested in Safari (WebKit)
|
|
||||||
- [ ] Fallbacks for modern CSS features (Grid, clamp, etc.)
|
|
||||||
|
|
||||||
## Testing Your Design
|
|
||||||
|
|
||||||
### Visual Testing
|
|
||||||
```bash
|
|
||||||
# Test responsive breakpoints
|
|
||||||
# Open browser DevTools → Toggle device toolbar
|
|
||||||
# Test at: 320px, 768px, 1024px, 1440px, 1920px
|
|
||||||
```
|
|
||||||
|
|
||||||
### Accessibility Testing
|
|
||||||
```bash
|
|
||||||
# Check color contrast
|
|
||||||
# Use WebAIM Contrast Checker: https://webaim.org/resources/contrastchecker/
|
|
||||||
|
|
||||||
# Test keyboard navigation
|
|
||||||
# Tab through all interactive elements
|
|
||||||
# Verify visible focus states
|
|
||||||
# Test with screen reader (VoiceOver on Mac, NVDA on Windows)
|
|
||||||
```
|
|
||||||
|
|
||||||
### Performance Testing
|
|
||||||
```bash
|
|
||||||
# Open browser DevTools → Performance tab
|
|
||||||
# Record page load and interactions
|
|
||||||
# Look for layout shifts (CLS)
|
|
||||||
# Verify animations run at 60fps
|
|
||||||
# Check for memory leaks with long animations
|
|
||||||
```
|
|
||||||
|
|
||||||
### Cross-Browser Testing
|
|
||||||
- Chrome/Edge: Primary testing
|
|
||||||
- Firefox: Verify CSS Grid/Flexbox behavior
|
|
||||||
- Safari: Test WebKit-specific issues
|
|
||||||
- Mobile browsers: Test touch interactions and viewport
|
|
||||||
|
|
@ -0,0 +1,258 @@
|
||||||
|
---
|
||||||
|
name: modern-git-workflow
|
||||||
|
description: >-
|
||||||
|
Standard de pointe pour l'ingénierie Git : interdiction formelle de développer sur la branche par défaut,
|
||||||
|
création systématique de feature branches courtes, commits atomiques conformes à Conventional Commits 1.0.0,
|
||||||
|
synchronisation par rebase pré-merge anti-conflits, intégration en Squash and Merge, stashes éphémères nommés
|
||||||
|
et Pull/Merge Requests multi-forges (GitHub, GitLab, Gitea).
|
||||||
|
---
|
||||||
|
|
||||||
|
# Modern Git Engineering Workflow
|
||||||
|
|
||||||
|
Ce skill formalise les standards actuels de l'industrie logicielle pour la gestion du cycle de vie du code sous Git. Il impose une hygiène rigoureuse : développement exclusivement sur branches isolées, commits atomiques et conventionnels, synchronisation linéaire par rebase, fusion par Squash and Merge, et gestion sécurisée du stash et des Pull Requests.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🎯 Règle Cardinale : Protection de la Branche par Défaut
|
||||||
|
|
||||||
|
> [!IMPORTANT]
|
||||||
|
> **Interdiction Absolue de Développer ou Commiter sur la Branche par Défaut**
|
||||||
|
> L'agent et le développeur ne doivent **JAMAIS** apporter de modifications de code directes ni effectuer de commit sur `main`, `master`, `trunk` ou `develop`.
|
||||||
|
>
|
||||||
|
> **Protocole Agent Obligatoire avant toute modification de fichier ou commit :**
|
||||||
|
> 1. Vérifier la branche courante : `git branch --show-current`
|
||||||
|
> 2. Si la branche retournée est la branche par défaut (`main`, `master`, `develop`) :
|
||||||
|
> - **Arrêt immédiat** de l'opération en cours.
|
||||||
|
> - Créer et basculer sur une branche dédiée : `git switch -c <type>/<nom-descriptif>`
|
||||||
|
> 3. Ne reprendre le travail ou les commits que sur cette branche isolée.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. 🎯 Norme Actuelle de Référence & Spécifications Officielles
|
||||||
|
|
||||||
|
Ce workflow s'appuie sur quatre piliers normatifs majeurs de l'ingénierie logicielle contemporaine :
|
||||||
|
|
||||||
|
1. **GitHub Flow Moderne & Short-Lived Feature Branches** :
|
||||||
|
- Branches éphémères de courte durée de vie (quelques heures à 2-3 jours maximum) dérivées de `main`.
|
||||||
|
- Réduction drastique des divergences de branches et des "merge hells".
|
||||||
|
2. **Spécification Conventional Commits v1.0.0** :
|
||||||
|
- Structure sémantique standardisée : `<type>(<scope optionnel>): <description en mode impératif>`.
|
||||||
|
- Compatibilité native avec le Semantic Versioning (SemVer) et la génération automatisée de changelogs.
|
||||||
|
3. **Plumbing & Porcelain Git Moderne (Git 2.23+)** :
|
||||||
|
- Abandon des usages ambigus de `git checkout` au profit des commandes spécialisées `git switch` et `git restore`.
|
||||||
|
- Utilisation de `git push --force-with-lease` pour protéger l'historique collaboratif lors des réécritures post-rebase.
|
||||||
|
4. **Sécurité AppSec & Secrets Management (OWASP)** :
|
||||||
|
- Contrôle strict de l'index (`git diff --staged`) pour interdire le commit accidentel de secrets (`.env`, tokens, clés privées).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. ✅ Bonnes Pratiques (Do's) vs ❌ Anti-patterns & Pièges (Don'ts)
|
||||||
|
|
||||||
|
| Sujet | ✅ Bonnes Pratiques (Do's) | ❌ Anti-patterns & Pièges à Bannir (Don'ts) |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| **Branche de travail** | Créer une branche dédiée préfixée (`feat/auth-jwt`, `fix/cache-ttl`) depuis `origin/main` à jour. | Commiter directement sur `main`, `master` ou `develop`. |
|
||||||
|
| **Messages de commit** | Conventional Commits : `feat(api): add idempotency key check` (impératif, minuscule, sans point final). | Messages vagues, paresseux ou génériques : `fix`, `wip`, `update`, `test bug`. |
|
||||||
|
| **Taille des commits** | Commits atomiques : une seule intention logique vérifiable avec tests passants. | Méga-commits mélangeant refactorisation, correction de bug et ajout de dépendances. |
|
||||||
|
| **Synchronisation** | Rebaser sur la branche cible avant merge : `git fetch` puis `git rebase origin/main`. | Fusionner `main` dans la feature branch via `git merge main` (accumulation de merge commits polluants). |
|
||||||
|
| **Push post-rebase** | Toujours utiliser `git push --force-with-lease` pour sécuriser le remote contre les écrasements. | Utiliser `git push --force` (`-f`) aveugle qui écrase le travail des collaborateurs. |
|
||||||
|
| **Stratégie de fusion** | **Squash and Merge** pour intégrer la PR sur `main` en 1 commit synthétique, propre et bisectionnable. | Fusions sans squash créant un graphe de commits "spaghetti" et des commits WIP sur `main`. |
|
||||||
|
| **Gestion du stash** | Nommer explicitement le stash avec `-u` : `git stash push -u -m "wip user profile"` et dépiler immédiatement (`git stash pop`). | Empiler des `git stash` anonymes oubliés sans inclure les fichiers non suivis. |
|
||||||
|
| **Hygiène de staging** | Examiner systématiquement `git diff --staged` avant de commiter pour filtrer secrets et fichiers temporaires. | Exécuter aveuglément `git add .` ou `git add -A` sans inspecter l'index. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. 📐 Architecture & Flux Étape par Étape
|
||||||
|
|
||||||
|
### 3.1 Cycle de Vie d'une Feature Branch (Mermaid `gitGraph`)
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
gitGraph
|
||||||
|
commit id: "Initial commit"
|
||||||
|
commit id: "feat: add user schema"
|
||||||
|
branch feat/login-endpoint
|
||||||
|
checkout feat/login-endpoint
|
||||||
|
commit id: "feat(auth): add login controller"
|
||||||
|
commit id: "test(auth): add unit tests for login"
|
||||||
|
checkout main
|
||||||
|
commit id: "fix(core): update dependencies"
|
||||||
|
checkout feat/login-endpoint
|
||||||
|
merge main id: "Rebase origin/main"
|
||||||
|
checkout main
|
||||||
|
merge feat/login-endpoint id: "Squash & Merge PR #1"
|
||||||
|
commit id: "docs: update API documentation"
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 3.2 Algorithme de Contrôle Agentique (Mermaid `flowchart TD`)
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
flowchart TD
|
||||||
|
A[Nouvelle Tâche ou Modification Demandée] --> B{Vérifier branche courante<br/>git branch --show-current}
|
||||||
|
B -- Est main, master ou develop --> C[Alerte: Branche protégée !]
|
||||||
|
C --> D[git switch -c type/nom-de-feature origin/main]
|
||||||
|
D --> E[Implémentation des changements]
|
||||||
|
B -- Est une feature branch valide --> E
|
||||||
|
|
||||||
|
E --> F[Vérifications locales: Lint, Typage & Tests unitaires]
|
||||||
|
F -- Échec --> E
|
||||||
|
F -- Succès --> G[git diff --staged : Audit anti-secrets & fichiers temporaires]
|
||||||
|
G --> H[Commit atomique: Conventional Commits 1.0.0]
|
||||||
|
|
||||||
|
H --> I{Fin de la feature ?}
|
||||||
|
I -- Non --> E
|
||||||
|
I -- Oui --> J[git fetch origin main]
|
||||||
|
J --> K[git rebase origin/main]
|
||||||
|
K -- Conflits --> L[Résolution méthodique étape par étape]
|
||||||
|
L --> K
|
||||||
|
K -- Succès --> M[Tests de validation post-rebase]
|
||||||
|
M --> N[git push --force-with-lease origin feat/...]
|
||||||
|
N --> O[Création de la PR/MR avec template universel]
|
||||||
|
O --> P[Validation finale ➔ Squash and Merge sur main]
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. 💻 Protocoles & Scénarios d'Exécution Guidés
|
||||||
|
|
||||||
|
### 4.1 Convention de Nommage des Branches
|
||||||
|
|
||||||
|
Chaque branche doit suivre le format : `<type>/<nom-descriptif-en-kebab-case>`
|
||||||
|
|
||||||
|
| Préfixe | Usage | Exemple |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| `feat/` | Nouvelle fonctionnalité métier ou technique | `feat/oauth2-google-login` |
|
||||||
|
| `fix/` | Correction d'une anomalie ou d'un bug | `fix/session-expiry-race-condition` |
|
||||||
|
| `refactor/` | Restructuration de code sans modification de comportement | `refactor/database-connection-pool` |
|
||||||
|
| `chore/` | Tâches de maintenance, dépendances, configuration | `chore/upgrade-typescript-5` |
|
||||||
|
| `docs/` | Modification exclusive de la documentation | `docs/openapi-swagger-spec` |
|
||||||
|
| `test/` | Ajout ou fiabilisation de tests automatisés | `test/e2e-checkout-flow` |
|
||||||
|
| `perf/` | Optimisation des performances | `perf/cache-redis-product-list` |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4.2 Spécification Conventional Commits 1.0.0
|
||||||
|
|
||||||
|
Chaque commit doit respecter la structure :
|
||||||
|
```text
|
||||||
|
<type>(<scope optionnel>): <sujet impératif en minuscules>
|
||||||
|
|
||||||
|
[Corps explicatif optionnel détaillant le POURQUOI et les arbitrages techniques]
|
||||||
|
|
||||||
|
[Références de tickets ou mention de rupture]
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Règles Typographiques :
|
||||||
|
- **Sujet** : Verbe à l'impératif présent (`add`, `fix`, `refactor`, `remove`), en minuscules, sans point final, 50-72 caractères max.
|
||||||
|
- **Rupture de compatibilité (Breaking Change)** : Ajouter un `!` après le type/scope ou un pied de page `BREAKING CHANGE: <description>`.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Exemple de commit standard
|
||||||
|
git commit -m "feat(auth): add rate limiting to login endpoint"
|
||||||
|
|
||||||
|
# Exemple de commit avec breaking change
|
||||||
|
git commit -m "refactor(api)!: drop legacy v1 authentication endpoints
|
||||||
|
|
||||||
|
BREAKING CHANGE: The /v1/auth route has been removed. All clients must migrate to /v2/tokens."
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4.3 Protocole de Synchronisation par Rebase (Pré-Merge Anti-Conflits)
|
||||||
|
|
||||||
|
Avant toute fusion ou ouverture finale de PR :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. S'assurer que le répertoire de travail est propre
|
||||||
|
git status
|
||||||
|
|
||||||
|
# 2. Récupérer l'état le plus récent de la branche cible
|
||||||
|
git fetch origin main
|
||||||
|
|
||||||
|
# 3. Rebaser votre feature branch sur la branche cible
|
||||||
|
git rebase origin/main
|
||||||
|
|
||||||
|
# 4. En cas de conflit : consulter le guide de résolution
|
||||||
|
# (voir references/conflict-resolution.md)
|
||||||
|
|
||||||
|
# 5. Relancer la suite de tests pour valider l'intégrité
|
||||||
|
npm test # ou pytest, cargo test, etc.
|
||||||
|
|
||||||
|
# 6. Pousser avec sécurité anti-écrasement
|
||||||
|
git push --force-with-lease origin feat/votre-feature
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4.4 Stratégie de Fusion Finale : Squash and Merge
|
||||||
|
|
||||||
|
La stratégie d'intégration standardisée est le **Squash and Merge** :
|
||||||
|
- **Pourquoi ?** Il condense l'ensemble des commits intermédiaires d'une feature branch en **un seul commit atomique, propre et parfait** sur la branche `main`.
|
||||||
|
- **Avantages majeurs** :
|
||||||
|
- Historique de `main` 100% linéaire et limpide.
|
||||||
|
- Facilité de retour arrière immédiat (`git revert <commit_sha>`).
|
||||||
|
- Efficacité absolue de `git bisect` pour détecter une régression sans tomber sur des commits intermédiaires cassés.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4.5 Protocole Stash Éphémère & Sécurisé
|
||||||
|
|
||||||
|
Le stash est un tampon volatile à courte durée de vie. Ne jamais laisser de stashes anonymes orphelins.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. Sauvegarder l'état en cours en incluant les nouveaux fichiers (-u) avec un motif clair
|
||||||
|
git stash push -u -m "wip: tentative refactorisation token service"
|
||||||
|
|
||||||
|
# 2. Effectuer l'opération urgente (ex: bascule de branche, pull urgent)
|
||||||
|
git switch fix/urgent-bug
|
||||||
|
|
||||||
|
# 3. De retour sur la branche, vérifier le stash
|
||||||
|
git stash list
|
||||||
|
|
||||||
|
# 4. Réappliquer immédiatement et dépiler
|
||||||
|
git stash pop
|
||||||
|
|
||||||
|
# En cas d'alternative pour du travail parallèle lourd : privilégier `git worktree`
|
||||||
|
# (voir references/git-commands-cheat-sheet.md)
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4.6 Pull Requests & Merge Requests Multi-Forges
|
||||||
|
|
||||||
|
Le skill prend en charge toutes les forges logicielles courantes :
|
||||||
|
1. **Détection du remote** : `git remote get-url origin`
|
||||||
|
2. **Si GitHub et `gh` installé** :
|
||||||
|
```bash
|
||||||
|
gh pr create --base main --head <branche> --title "<type>(<scope>): <titre>" --body "..."
|
||||||
|
```
|
||||||
|
3. **Si GitLab et `glab` installé** :
|
||||||
|
```bash
|
||||||
|
glab mr create --target-branch main --source-branch <branche> --title "<type>(<scope>): <titre>"
|
||||||
|
```
|
||||||
|
4. **Pour Gitea ou toute interface web** : Utiliser systématiquement le [Gabarit Universel de Pull Request](./references/pr-templates.md).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. 📋 Checklist de Conformité & Références Officielles
|
||||||
|
|
||||||
|
### Checklist de l'Agent avant Clôture d'une Tâche Git :
|
||||||
|
- [ ] Le travail a été réalisé sur une branche dédiée (jamais sur `main`/`master`/`develop`).
|
||||||
|
- [ ] Le nom de la branche respecte la taxonomie (`feat/...`, `fix/...`, etc.).
|
||||||
|
- [ ] Chaque commit suit la norme **Conventional Commits 1.0.0**.
|
||||||
|
- [ ] Aucun secret, mot de passe, clé d'API ou token n'a été indexé.
|
||||||
|
- [ ] Les tests automatisés et linters s'exécutent avec succès en local.
|
||||||
|
- [ ] La branche a été rebasée sur `origin/main` sans conflit résiduel.
|
||||||
|
- [ ] Le push a été réalisé avec `--force-with-lease` (jamais de `--force` brut).
|
||||||
|
- [ ] La description de la PR / MR respecte le gabarit universel avec plan de test documenté.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Références & Documentation Associée
|
||||||
|
|
||||||
|
- **[Gabarits Universels de PR & MR](./references/pr-templates.md)** : Modèles complets pour GitHub, GitLab et Gitea.
|
||||||
|
- **[Guide de Résolution de Conflits](./references/conflict-resolution.md)** : Procédure pas à pas en 5 étapes lors du rebase.
|
||||||
|
- **[Aide-Mémoire des Commandes Git Modernes](./references/git-commands-cheat-sheet.md)** : Référence rapide des commandes `switch`, `restore`, `stash push -u`, `worktree`.
|
||||||
|
- **[Spécification Conventional Commits 1.0.0](https://www.conventionalcommits.org/en/v1.0.0/)** : Standard officiel des messages de commit.
|
||||||
|
- **[Git Documentation Officielle](https://git-scm.com/doc)** : Documentation de référence du moteur Git.
|
||||||
|
- **[OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)** : Bonnes pratiques de prévention des fuites de données d'authentification dans le code source.
|
||||||
|
|
@ -0,0 +1,121 @@
|
||||||
|
# Protocole Méthodique de Résolution des Conflits de Rebase
|
||||||
|
|
||||||
|
Lors d'un `git rebase origin/main`, Git rejoue chaque commit de votre branche un par un au-dessus du dernier commit de la branche cible. Si un conflit survient, Git met le processus en pause. Ce document détaille la démarche méthodique et sécurisée pour résoudre les conflits sans perte de code.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Comprendre la Mécanique du Rebase
|
||||||
|
|
||||||
|
Contrairement à un `git merge` où les deux branches fusionnent en créant un nouveau commit de fusion, le rebase déplace la racine de votre branche.
|
||||||
|
Dans les marqueurs de conflit lors d'un rebase :
|
||||||
|
- `<<<<<<< HEAD` représente le code de la branche cible (`origin/main`) sur lequel vous êtes en train de vous caler.
|
||||||
|
- `=======` sépare les deux versions.
|
||||||
|
- `>>>>>>> <votre_commit>` représente le code que votre commit essayait d'appliquer.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Le Protocole en 5 Étapes
|
||||||
|
|
||||||
|
```text
|
||||||
|
[Conflit détecté]
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
1. git status (Cartographier les fichiers "both modified")
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
2. Résoudre les marqueurs de conflit dans l'éditeur (<<<<<<<, =======, >>>>>>>)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
3. git add <fichier_résolu> (Ne JAMAIS faire git commit !)
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
4. git rebase --continue
|
||||||
|
│
|
||||||
|
▼
|
||||||
|
5. Lancer la suite de tests (pytest, npm test...) ➔ Validation finale
|
||||||
|
```
|
||||||
|
|
||||||
|
### Étape 1 : Cartographier les Conflits
|
||||||
|
Dès que Git indique `CONFLICT (content): Merge conflict in ...`, inspectez l'état :
|
||||||
|
```bash
|
||||||
|
git status
|
||||||
|
```
|
||||||
|
Repérez les fichiers sous la section `Unmerged paths:` marqués en `both modified:`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Étape 2 : Résolution Sémantique
|
||||||
|
Ouvrez chaque fichier en conflit dans votre éditeur.
|
||||||
|
Analysez les deux blocs :
|
||||||
|
```javascript
|
||||||
|
<<<<<<< HEAD
|
||||||
|
// Code présent sur origin/main (modifié par un autre contributeur ou une autre PR)
|
||||||
|
const sessionTimeout = 3600;
|
||||||
|
=======
|
||||||
|
// Votre modification issue du commit en cours de rejeu
|
||||||
|
const sessionTimeout = 7200;
|
||||||
|
const gracePeriod = 30;
|
||||||
|
>>>>>>> 3a8f1b2 (feat(auth): increase session timeout and add grace period)
|
||||||
|
```
|
||||||
|
Conservez la logique métier appropriée, supprimez les marqueurs `<<<<<<<`, `=======`, et `>>>>>>>`, et sauvegardez.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Étape 3 : Marquer comme Résolu (Stage)
|
||||||
|
Ajoutez les fichiers résolus à l'index Git :
|
||||||
|
```bash
|
||||||
|
git add src/auth/session.js
|
||||||
|
```
|
||||||
|
|
||||||
|
> [!CAUTION]
|
||||||
|
> **Ne jamais exécuter `git commit` pendant un rebase !**
|
||||||
|
> L'exécution d'un commit manuel dans cet état briserait la séquence du rebase. Vous devez exclusivement utiliser `git rebase --continue`.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Étape 4 : Poursuivre le Rebase
|
||||||
|
Demandez à Git de rejouer les commits suivants :
|
||||||
|
```bash
|
||||||
|
git rebase --continue
|
||||||
|
```
|
||||||
|
- Si Git s'arrête à nouveau sur un autre commit, répétez les étapes 1 à 4.
|
||||||
|
- Lorsque tous les commits sont rejoués avec succès, Git affiche :
|
||||||
|
`Successfully rebased and updated refs/heads/<votre_branche>.`
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Étape 5 : Validation et Push Sécurisé
|
||||||
|
Avant tout push, validez que l'application compile et que tous les tests passent :
|
||||||
|
```bash
|
||||||
|
# Exemple pour Node / TypeScript
|
||||||
|
npm run lint && npm test
|
||||||
|
|
||||||
|
# Exemple pour Python
|
||||||
|
ruff check . && pytest
|
||||||
|
```
|
||||||
|
|
||||||
|
Poussez ensuite la branche vers le remote. Puisque l'historique a été réécrit localement, vous devez forcer le push, mais **exclusivement avec `--force-with-lease`** :
|
||||||
|
```bash
|
||||||
|
git push --force-with-lease origin feat/votre-feature
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Gestion des Cas d'Urgence & Règles de Sécurité
|
||||||
|
|
||||||
|
### ⚠️ Annulation Immédiate (Rollback Propre)
|
||||||
|
Si la résolution devient confuse, incertaine ou que des conflits inattendus apparaissent :
|
||||||
|
```bash
|
||||||
|
git rebase --abort
|
||||||
|
```
|
||||||
|
Cette commande restaure immédiatement votre branche à son état exact avant le lancement du rebase. Aucune donnée n'est perdue.
|
||||||
|
|
||||||
|
### 🚫 Interdiction de `git rebase --skip` sans Audit
|
||||||
|
Ne lancez `git rebase --skip` **que si et seulement si** le commit en cours de rejeu a été intégralement intégré dans la branche cible par une autre PR, rendant votre commit complètement vide. Lancer `--skip` à la légère efface purement et simplement le travail contenu dans ce commit.
|
||||||
|
|
||||||
|
### 🔍 Cas Particulier : Commit Devenu Vide
|
||||||
|
Si votre commit est devenu vide parce que ses changements sont déjà présents sur `origin/main`, Git vous invitera à utiliser :
|
||||||
|
```bash
|
||||||
|
git rebase --skip
|
||||||
|
```
|
||||||
|
Vérifiez toujours au préalable avec `git diff HEAD origin/main` que vos modifications sont bien effectives sur la branche cible avant de sauter le commit.
|
||||||
|
|
@ -0,0 +1,87 @@
|
||||||
|
# Aide-Mémoire des Commandes Git Modernes
|
||||||
|
|
||||||
|
Ce mémento rassemble les commandes recommandées par les standards actuels de l'ingénierie logicielle, privilégiant les commandes spécialisées introduites dans les versions récentes de Git (`switch`, `restore`, `stash push -u`, `--force-with-lease`).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Gestion des Branches (`git switch`)
|
||||||
|
|
||||||
|
Depuis Git 2.23+, `git switch` remplace `git checkout` pour toutes les manipulations de branches.
|
||||||
|
|
||||||
|
| Opération | Commande Moderne | Éviter (Obsolète / Ambigu) |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| **Créer & basculer sur une feature branch** | `git switch -c feat/nom-feature` | `git checkout -b ...` |
|
||||||
|
| **Créer une branche depuis `origin/main` à jour** | `git switch -c feat/nom-feature origin/main` | `git checkout -b ... origin/main` |
|
||||||
|
| **Revenir sur la branche principale** | `git switch main` | `git checkout main` |
|
||||||
|
| **Bascule rapide sur la branche précédente** | `git switch -` | `git checkout -` |
|
||||||
|
| **Supprimer une branche locale fusionnée** | `git branch -d feat/nom-feature` | `git branch -D ...` *(sauf abandon explicite)* |
|
||||||
|
| **Nettoyer les références de branches supprimées à distance** | `git remote prune origin` ou `git fetch --prune` | |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Annulation & Restauration de Fichiers (`git restore`)
|
||||||
|
|
||||||
|
`git restore` remplace les usages dangereux de `git checkout -- <file>` ou `git reset HEAD <file>`.
|
||||||
|
|
||||||
|
| Opération | Commande Moderne | Description |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| **Désindexer un fichier (unstage)** | `git restore --staged <fichier>` | Retire le fichier du staging sans perdre les modifications locales. |
|
||||||
|
| **Désindexer tous les fichiers stagés** | `git restore --staged .` | Équivalent propre de `git reset`. |
|
||||||
|
| **Annuler les modifications locales d'un fichier** | `git restore <fichier>` | Remet le fichier à l'état du dernier commit (attention : irréversible). |
|
||||||
|
| **Restaurer un fichier depuis une autre branche** | `git restore --source origin/main -- <fichier>` | Récupère la version exacte d'un fichier depuis `main`. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Protocole Stash Sécurisé (`git stash push`)
|
||||||
|
|
||||||
|
| Opération | Commande Moderne | Pourquoi ? |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| **Stasher avec nom et fichiers untracked** | `git stash push -u -m "contexte explicite"` | `-u` inclut les nouveaux fichiers créés ; le message évite les stash anonymes orphelins. |
|
||||||
|
| **Stasher uniquement certains fichiers** | `git stash push -m "contexte" path/to/file` | Isole une modification sans stasher tout le répertoire. |
|
||||||
|
| **Lister les stashes existants** | `git stash list` | Affiche l'index et les libellés descriptifs. |
|
||||||
|
| **Consulter le contenu d'un stash** | `git stash show -p stash@{0}` | Affiche le diff exact contenu dans le stash avant de l'appliquer. |
|
||||||
|
| **Restaurer et supprimer le stash (dépilage)** | `git stash pop` | Réapplique les modifications et supprime l'entrée de la liste. |
|
||||||
|
| **Restaurer sans supprimer de la liste** | `git stash apply stash@{0}` | Utile pour tester l'application d'un stash sans le détruire. |
|
||||||
|
| **Supprimer un stash spécifique** | `git stash drop stash@{0}` | Nettoie un stash devenu inutile. |
|
||||||
|
| **Vider intégralement tous les stashes** | `git stash clear` | À utiliser avec précaution après vérification de `git stash list`. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Rebase, Nettoyage & Synchronisation
|
||||||
|
|
||||||
|
| Opération | Commande Moderne | Description |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| **Mettre à jour la cible distante** | `git fetch origin main` | Récupère les derniers commits distants sans toucher à l'arbre local. |
|
||||||
|
| **Rebaser la branche courante sur `origin/main`** | `git rebase origin/main` | Rejoue les commits locaux au-dessus de `origin/main`. |
|
||||||
|
| **Rebase interactif des N derniers commits** | `git rebase -i HEAD~N` | Permet de fusionner (`squash`), renommer (`reword`) ou réordonner les commits locaux. |
|
||||||
|
| **Poursuivre le rebase après résolution de conflit** | `git rebase --continue` | Après avoir fait `git add <fichier_résolu>`. |
|
||||||
|
| **Annuler un rebase en cours** | `git rebase --abort` | Restaure immédiatement la branche à son état pré-rebase. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Push Sécurisé & Intégration
|
||||||
|
|
||||||
|
| Opération | Commande Moderne | Danger de l'alternative |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| **Pousser une nouvelle feature branch** | `git push -u origin feat/nom-feature` | Configure l'upstream pour les prochains `git push`/`git pull`. |
|
||||||
|
| **Pousser après un rebase local** | `git push --force-with-lease origin feat/nom-feature` | **CRITIQUE** : `--force-with-lease` refuse d'écraser le remote si un collègue a poussé des commits entre-temps, évitant la perte de code provoquée par `--force`. |
|
||||||
|
| **Vérifier les commits prêts à être poussés** | `git log origin/main..HEAD --oneline` | Affiche uniquement les commits propres à votre branche non encore fusionnés sur `main`. |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Alternative Avancée au Stash : `git worktree`
|
||||||
|
|
||||||
|
Pour travailler en parallèle sur un correctif urgent sans stasher ni changer de branche dans le dossier courant :
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. Créer un dossier de travail dédié pour la nouvelle branche
|
||||||
|
git worktree add ../mon-projet-hotfix -b fix/urgent-auth-bug origin/main
|
||||||
|
|
||||||
|
# 2. Travailler dans le dossier ../mon-projet-hotfix de manière complètement isolée
|
||||||
|
cd ../mon-projet-hotfix
|
||||||
|
# ... commits, tests, push ...
|
||||||
|
|
||||||
|
# 3. Une fois terminé et la PR ouverte, nettoyer le worktree
|
||||||
|
cd ../mon-projet
|
||||||
|
git worktree remove ../mon-projet-hotfix
|
||||||
|
```
|
||||||
|
|
@ -0,0 +1,113 @@
|
||||||
|
# Gabarits Universels de Pull Request & Merge Request
|
||||||
|
|
||||||
|
Ce document fournit des modèles structurés pour rédiger des Pull Requests (GitHub, Gitea) et Merge Requests (GitLab) professionnelles, complètes et conformes aux standards de l'art.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Modèle Standard Universel (Markdown)
|
||||||
|
|
||||||
|
Ce gabarit doit être utilisé dans le corps de description de la PR/MR, quel que soit l'outil ou la forge utilisée.
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## 🎯 Contexte & Objectif
|
||||||
|
<!-- Expliquez brièvement le problème résolu ou le besoin fonctionnel/technique auquel répond cette branche. -->
|
||||||
|
<!-- Ex: Résout l'anomalie #42 liée à l'expiration prématurée des sessions d'authentification. -->
|
||||||
|
|
||||||
|
Refs / Closes #<NUMERO_ISSUE>
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🛠️ Modifications apportées
|
||||||
|
<!-- Liste à puces synthétique des changements clés introduits dans cette PR. -->
|
||||||
|
- Ajout du middleware de validation des tokens avec délai de grâce de 30 secondes.
|
||||||
|
- Mise à jour du schéma de base de données pour inclure la date d'invalidation de session.
|
||||||
|
- Refactorisation du service de gestion des utilisateurs pour éviter les requêtes N+1.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🧪 Stratégie de Test & Preuves de Fonctionnement
|
||||||
|
<!-- Décrivez comment vous avez testé vos modifications et joignez logs ou captures si pertinent. -->
|
||||||
|
- [x] **Tests unitaires & intégration** : `pytest` / `npm test` exécutés avec 100% de succès.
|
||||||
|
- [x] **Linter & Typage** : Aucun avertissement (`ruff check`, `eslint`, `tsc --noEmit`).
|
||||||
|
- [x] **Vérification manuelle** : Parcours utilisateur testé en environnement local (login ➔ renouvellement ➔ déconnexion).
|
||||||
|
|
||||||
|
```text
|
||||||
|
<!-- Collez un extrait concis de log ou résultat de test réussi -->
|
||||||
|
PASS tests/auth/test_session_invalidation.py (14 tests passed in 0.82s)
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 📋 Checklist de Sécurité & Hygiène Git
|
||||||
|
<!-- Vérifiez chaque point avant de soumettre ou de valider la PR. -->
|
||||||
|
- [x] La branche a été rebasée sur la dernière version de la branche cible (`origin/main`).
|
||||||
|
- [x] Aucun secret, clé d'API, mot de passe ou fichier sensible (`.env`, `.pem`) n'est présent dans le diff.
|
||||||
|
- [x] Aucun fichier temporaire, log ou déchet de build n'est inclus (`.DS_Store`, `node_modules/`, `dist/`).
|
||||||
|
- [x] Les messages de commit respectent la spécification **Conventional Commits 1.0.0**.
|
||||||
|
- [x] La PR est prête pour une fusion par **Squash and Merge** (ou Rebase and Merge si commits atomiques validés).
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Commandes CLI par Forge Logicielle
|
||||||
|
|
||||||
|
### 2.1 GitHub (`gh` CLI)
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. Ouvrir une PR standard
|
||||||
|
gh pr create \
|
||||||
|
--base main \
|
||||||
|
--head feat/auth-token-refresh \
|
||||||
|
--title "feat(auth): add automatic session token grace period" \
|
||||||
|
--body-file .github/pull_request_template.md
|
||||||
|
|
||||||
|
# 2. Ouvrir une PR en mode Draft (travail en cours ou en attente de retours)
|
||||||
|
gh pr create --draft \
|
||||||
|
--base main \
|
||||||
|
--title "feat(auth): add automatic session token grace period [WIP]" \
|
||||||
|
--body "Travail en cours, tests en phase de stabilisation."
|
||||||
|
|
||||||
|
# 3. Marquer une PR Draft comme prête pour la revue
|
||||||
|
gh pr ready <NUMERO_PR>
|
||||||
|
|
||||||
|
# 4. Fusionner via Squash and Merge
|
||||||
|
gh pr merge <NUMERO_PR> --squash --delete-branch
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.2 GitLab (`glab` CLI)
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# 1. Ouvrir une Merge Request standard
|
||||||
|
glab mr create \
|
||||||
|
--target-branch main \
|
||||||
|
--source-branch feat/auth-token-refresh \
|
||||||
|
--title "feat(auth): add automatic session token grace period" \
|
||||||
|
--description "Description complète..." \
|
||||||
|
--remove-source-branch \
|
||||||
|
--squash-before-merge
|
||||||
|
|
||||||
|
# 2. Ouvrir en mode Draft / Work in Progress
|
||||||
|
glab mr create --draft \
|
||||||
|
--target-branch main \
|
||||||
|
--title "Draft: feat(auth): add automatic session token grace period"
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 2.3 Gitea & Forges Génériques
|
||||||
|
|
||||||
|
Pour Gitea ou toute forge sans outil CLI installé en local :
|
||||||
|
|
||||||
|
1. Pousser la branche de travail vers le dépôt distant :
|
||||||
|
```bash
|
||||||
|
git push -u origin feat/auth-token-refresh
|
||||||
|
```
|
||||||
|
2. Git affichera dans la console le lien direct pour créer la Pull Request sur l'interface web de Gitea :
|
||||||
|
```text
|
||||||
|
remote: Create a pull request for 'feat/auth-token-refresh' on Gitea by visiting:
|
||||||
|
remote: https://gitea.example.com/org/repo/compare/main...feat/auth-token-refresh
|
||||||
|
```
|
||||||
|
3. Remplir le formulaire avec le titre conventionnel et le corps Markdown universel ci-dessus.
|
||||||
|
4. Sélectionner l'option **Squash and Merge** lors de l'approbation finale.
|
||||||
Loading…
Reference in New Issue