Repository navigation
Guide Git GitHub
Fichier : Guide-Git-GitHub.md · Dossier : wiki racine (
~/projet_zeta/Riemann_Lab.wiki/) Branche : master · Auteur : hprzeta · MAJ : 2026-06-21
Principe fondamental : tout se fait en LOCAL, puis on pousse vers GitHub. Ne jamais modifier directement sur GitHub (sauf urgence).
| Icône | Idée d'usage |
|---|---|
| 🧭 | Navigation, guide, workflow |
| 🔬 | Tests, résultats, analyse |
| 📐 | Théorie, mathématiques |
| 📊 | Graphiques, données, stats |
| 🧮 | Calculs, scripts |
| 📝 | Notes, documentation |
| 🗂️ | Organisation, structure |
| 🚀 | Lancement, déploiement |
| 🔧 | Configuration, maintenance |
| 🐛 | Bug, correction |
| ✅ | Validation, succès |
| Avertissement | |
| 📦 | Dépendances, packages |
| 🌿 | Branche Git |
| 🏷️ | Tag, version |
| 📌 | Point important |
| 🔗 | Lien, référence |
| 💡 | Idée, astuce |
| 🗒️ | Wiki, page |
| 🐙 | GitHub |
Fichiers locaux → git add → git commit → git push → GitHub
git pull → tu travailles → git add → git commit → git push
- Aller sur github.com → New repository
- Nommer le dépôt (ex:
projet_zeta) - Cocher Add a README
- Cliquer Create repository
cd ~/
git clone https://github.com/hprzeta/projet_zeta.git
cd projet_zeta# Dépôt principal
git clone https://github.com/hprzeta/projet_zeta.git
# Wiki du dépôt
git clone https://github.com/hprzeta/projet_zeta.wiki.gitcd ~/projet_zeta
git add src/tests/
git commit -m "docs: ajout interprétation test T40 — zéros ζ(s)"
git pushcd ~/projet_zeta
git add src/tests/interpreation_test/T40zero/compute_zeros_zeta.py
git commit -m "feat: script calcul zéros ζ(s) T40"
git pushcd ~/projet_zeta
git add .
git commit -m "chore: mise à jour générale"
git pushcd ~/projet_zeta/Riemann_Lab.wiki
git add "🔬-Interprétation-des-résultats-de-tests.md"
git commit -m "docs: ajout interprétation des résultats de tests T40 ζ(s)"
git push origin master# Voir ce qui a changé / ce qui est prêt à committer
git status
# Voir l'historique des commits
git log --oneline
# Voir les différences avant d'ajouter
git diff
# Voir les branches existantes
git branch -a# Créer une nouvelle branche et basculer dessus
git checkout -b T500-zeros
# Voir sur quelle branche on est
git branch
# Basculer sur une branche existante
git checkout master
# Pousser une nouvelle branche vers GitHub
git push origin T500-zeros
# Fusionner une branche dans master (depuis master)
git checkout master
git merge T500-zeros
# Supprimer une branche locale après fusion
git branch -d T500-zeros💡 Bonne pratique : une branche par expérience (ex:
T500-zeros,T1000-gue,refactor-illinois)
cd ~/projet_zeta
git mv ancien_nom.py nouveau_nom.py
git commit -m "refactor: renommage ancien_nom → nouveau_nom"
git push
⚠️ Toujours utilisergit mvplutôt quemvseul — Git garde ainsi l'historique du fichier.
# Annuler les modifications d'un fichier non encore commité
git checkout -- nom_du_fichier.py
# Annuler le dernier commit (en gardant les fichiers)
git reset --soft HEAD~1
# Voir un ancien commit
git show abc1234
# Revenir à une version antérieure d'un fichier
git checkout abc1234 -- nom_du_fichier.py# Créer un tag pour marquer une étape importante
git tag v0.1.0 -m "Première version — zéros T40 validés"
# Pousser le tag vers GitHub
git push origin v0.1.0💡 Suggestion pour projet_zeta : tagger chaque palier validé (
v0.1-T40,v0.2-T500, etc.)
cd ~/projet_zeta/Riemann_Lab.wiki
# Créer le fichier en local
touch "📐-Partie-2-Méthode-Illinois.md"
# … éditer le fichier …
git add "📐-Partie-2-Méthode-Illinois.md"
git commit -m "docs: ajout page méthode Illinois"
git push origin masterLes Issues se créent directement sur GitHub :
- Aller sur
github.com/hprzeta/projet_zeta→ onglet Issues - Cliquer New issue
- Titre : ex.
Zéro manqué quand STEP=0.1 et T_MAX=100 - Description : reproduire le problème, coller le log
- Assigner un label :
bug,enhancement,documentation...
💡 Dans un commit, écrire
fix #12fermera automatiquement l'issue n°12.
cd ~/projet_zeta
git pull
# Pour le wiki
cd ~/projet_zeta/Riemann_Lab.wiki
git pull origin master| Tag | Signification | Exemple |
|---|---|---|
feat |
Nouvelle fonctionnalité | feat: calcul zéros jusqu'à T500 |
fix |
Correction de bug | fix: zéro manqué STEP trop grand |
docs |
Documentation | docs: ajout interprétation T40 ζ(s) |
refactor |
Réécriture sans changer le comportement | refactor: simplification Illinois |
test |
Ajout/modification de tests | test: vérification T40 vs LMFDB |
chore |
Maintenance, config | chore: mise à jour mpmath |
style |
Mise en forme uniquement | style: reformatage compute_zeros.py |
perf |
Amélioration des performances | perf: réduction temps de balayage |
revert |
Annulation d'un commit | revert: annulation refactor Illinois |
# Voir ce que Git sait de mes dépôts distants
git remote -v
# Réparer un push refusé (si GitHub est en avance sur local)
git pull --rebase
git push
# Vider le cache Git (si un fichier ignoré persiste)
git rm -r --cached .
git add .
git commit -m "chore: nettoyage cache Git"# 1. Basculer sur la branche de test
git checkout Riemann_Lab_Test
# 2. Récupérer le code actuel de Riemann_Lab_IA
git merge Riemann_Lab_IA
# 3. Tu testes, tu modifies, tu casses...
python zeta_test.py
# 4. Si ça marche → tu ramènes dans Riemann_Lab_IA
git checkout Riemann_Lab_IA
git merge Riemann_Lab_Test
# 5. Si ça ne marche pas → aucun problème
# Riemann_Lab_IA est intact, tu recommencesbash
# 1. Aller dans ton projet
cd ~/projet_zeta
# 2. Vérifier où tu es
git branch # l'étoile * = branche active
# 3. Basculer si besoin
git checkout Riemann_Lab_IA
# 4. Récupérer les derniers changements
git pull origin Riemann_Lab_IA
# 5. Tu travailles...
# 6. Fin de session → pousser
git add .
git commit -m "feat: ..."
git push origin Riemann_Lab_IA
bash
cd ~/projet_zeta/Riemann_Lab.wiki
# Voir ce qui diffère entre local et distant
git status
git log --oneline -5
bash
cd ~/projet_zeta/Riemann_Lab.wiki
# Télécharger et fusionner les changements distants
git pull origin master
bash
cd ~/projet_zeta/Riemann_Lab.wiki
# Voir ce qui a changé
git status
# Ajouter tout
git add .
# Committer
git commit -m "docs: synchronisation wiki"
# Pousser
git push origin master
bash
git checkout Riemann_Lab_IA
git reset --hard origin/main
git push origin Riemann_Lab_IA --force
bash
git branch -m Riemann_Test Riemann_Lab_Test
git push origin --delete Riemann_Test
git push origin Riemann_Lab_Test
git branch --set-upstream-to=origin/Riemann_Lab_Test Riemann_Lab_Test
# Basculer sur Riemann_Lab_IA
git checkout Riemann_Lab_IA
bash
# Créer Riemann_Test localement depuis main
git checkout main
git checkout -b Riemann_Test
# La pousser sur GitHub avec un premier commit
git push -u origin Riemann_Test
# Vérifier
git branch -a
Quand tu colles un bloc de commandes fourni par une IA, repère les placeholders
du type ~/chemin/vers/fichier.md. Collé tel quel :
cp ~/chemin/vers/Handoff.md . # ÉCHOUE : "Aucun fichier ou dossier de ce nom"Le piège est que la suite devient une chaîne de non-opérations silencieuse :
cp échoue → git add ne trouve rien de neuf → git commit répond « aucune
modification » → git push répond « Everything up-to-date ». Aucune erreur
bloquante, mais rien n'a été poussé.
Réflexe : remplacer le placeholder par le vrai dossier (~/Téléchargements/),
puis vérifier juste après le cp :
cp ~/Téléchargements/Handoff.md .
head -3 Handoff.md # confirme que la BONNE version est bien là-
git rm fichierne marche que sur un fichier suivi (déjà committé). Sur un fichier non suivi →fatal: ... ne correspond à aucun fichier. - Pour supprimer un fichier non suivi (jamais committé) :
rm fichiertout court.
Le wiki GitHub ne sert que les fichiers committés ET poussés à la racine du repo wiki. Un fichier listé en rouge sous « Fichiers non suivis » n'a jamais quitté ta machine → aucun risque « public », même s'il traîne dans le dossier wiki.
Avant de paniquer sur un fichier « public », chercher d'abord un éventuel secret :
grep -iE "token|secret|key|password|ghp_|github_pat" fichier.mdVide = aucun danger. Sinon → secret exposé = secret mort → révocation immédiate
(voir Bonnes-Pratiques-Claude-Code.md, section Sécurité).
head -3 Handoff.md # la bonne version est-elle en place ?
git log --oneline -2 -- Handoff.md # le commit attendu touche-t-il bien ce fichier ?Handoff.md est local uniquement (~/projet_zeta/handoff/), jamais dans le wiki,
jamais dans docs/. Vérifier l'absence de doublon :
ls ~/projet_zeta/docs/handoff/Handoff.md 2>/dev/null # ne doit PAS exister
ls ~/projet_zeta/Riemann_Lab.wiki/Handoff.md 2>/dev/null # ne doit PAS existerfind . -name "*.md" -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort -r | head -20git check-ignore -v logs/*.log # vérifier avant tout git add -AUn fichier ignoré sur main peut ne pas l'être sur Riemann_Lab_C. Toujours vérifier
sur la branche active.
# Créer dossier de résultat
mkdir -p calculs/vX_TYYY_YYYYMMDD_HHMMSS/
cp logs/run_T*.log calculs/vX_TYYY_YYYYMMDD_HHMMSS/
cp calculs/vX_TYYY_YYYYMMDD_HHMMSS/*.csv . # copie de sécuritéPour un run > 30 min, surveiller le processus et estimer la durée avant de lancer :
# Vérifier que le run est actif (toutes les 5–10 min)
ps aux | grep compute_zeros | grep -v grep
# Suivre les logs en direct
tail -f calculs/run_T100k_step_delta3_*.log | grep -E "Worker|Turing|zéros"
# Estimation durée restante par worker j (formule approximée)
# v_j ≈ 40 / √(T_j / 10000) z/s
# durée ≈ (N(T_j) - N(T_{j-1})) / v_j secondesRègle vitesse : vérifier à 5 min après lancement. Si vitesse < 10 z/s → régression STEP probable → tuer le run et diagnostiquer.
Monitor Claude Code : lancer Monitor sur le fichier log avec pattern "Turing-Backlund".
Timeout max : 3 600 000 ms (1h). Si Monitor se déclenche → stopper toute tâche courante
et traiter le résultat du run en priorité.
# Exemple : run actif PID 328675, log run_T100k_step_delta3_20260610_1717.log
# Monitor déclenché → tail du log + validation Turing-Backlund :
tail -50 calculs/run_T100k_step_delta3_20260610_1717.loggh (GitHub CLI) permet de piloter GitHub depuis le terminal — créer des pull requests, gérer des issues, etc. — sans manipuler de token manuellement. C'est ce qui permet à Claude Code d'agir directement sur GitHub (ex. gh pr create) plutôt que de te renvoyer vers le site web.
gh auth loginRépondre aux questions interactives :
-
What account do you want to log into?→ GitHub.com -
What is your preferred protocol for Git operations?→ HTTPS -
Authenticate Git with your GitHub credentials?→ Yes -
How would you like to authenticate GitHub CLI?→ Login with a web browser
Le terminal affiche alors un code à 8 caractères (ex. 1272-E323) et une URL :
https://github.com/login/device
Étapes côté navigateur :
- Ouvrir cette URL
- Se connecter au compte
hprzeta - Entrer le code affiché dans le terminal
- Sur la page « Authorize GitHub CLI », vérifier les permissions demandées :
- Gists
- Organizations (lecture seule)
- Repositories (publics + privés) ← permission essentielle pour créer des PR
- Cliquer Authorize github
Le terminal se débloque automatiquement dès l'autorisation validée. Vérifier le résultat :
gh auth status
# ✓ Logged in to github.com account hprzeta (keyring)
# - Token scopes: 'gist', 'read:org', 'repo'
⚠️ Le code expire après 1 minute. S'il expire avant la validation côté navigateur, relancer simplementgh auth login.
Une fois authentifié, créer une PR directement depuis le terminal (sans passer par le formulaire web) :
gh pr create --base <branche_cible> --head <branche_source> \
--title "docs(ops): titre court" \
--body "Description de la PR"Prérequis : la branche source (--head) doit déjà être poussée sur GitHub (git push -u origin <branche>).
gh signale au passage les fichiers non commités/untracked présents dans le répertoire de travail (Warning: N uncommitted changes) — c'est informatif, ça n'empêche pas la création de la PR.
Résultat : l'URL de la PR créée s'affiche directement, par exemple :
https://github.com/hprzeta/Riemann_Lab/pull/6
Si gh n'est pas authentifié, git push d'une nouvelle branche affiche déjà un lien direct vers le formulaire de création de PR :
remote: Create a pull request for 'ma-branche' on GitHub by visiting:
remote: https://github.com/hprzeta/Riemann_Lab/pull/new/ma-branche
Ouvrir ce lien dans un navigateur et remplir le formulaire GitHub manuellement (titre, description, branche cible).
gh refuse une opération (push, gh pr create, etc.) en signalant que le token est expiré
ou invalide. Le token GitHub CLI a une durée de vie limitée et doit être renouvelé
périodiquement — ce n'est pas une anomalie, c'est attendu.
gh auth loginRépondre aux questions interactives (identique à la procédure §22) :
-
What account do you want to log into?→ GitHub.com -
What is your preferred protocol for Git operations?→ HTTPS -
How would you like to authenticate GitHub CLI?→ Login with a web browser
Ouvrir l'URL affichée (https://github.com/login/device), entrer le code à 8 caractères,
se connecter au compte hprzeta, puis Authorize github.
Vérifier le résultat :
gh auth status💡 Réflexe avant toute session Git/GitHub : si une commande
ghéchoue de façon inattendue, vérifier d'abordgh auth statusavant de chercher un autre bug — un token expiré est la cause la plus fréquente et la plus rapide à corriger.
Guide-Git-GitHub.md · wiki racine · branche master · hprzeta · MAJ 2026-06-23 · 632 lignes