ITTA propose un catalogue Git : Git Fondamentaux (init, commit, branches, merge, rebase, GitFlow, GitHub Flow, conflits, tags). Cette formation s’adresse aux développeurs, intégrateurs, ingénieurs DevOps, data scientists et profils tech qui veulent professionnaliser leur workflow de versionning. Dispensée à Genève, Lausanne et en classe virtuelle interactive par des développeurs en activité.
FILTRER PAR
- Domaines
- Editeurs
- Lieu
- Format
- Niveau
- Certifiant
- Cours confirmé
Formation Git pour apprendre versioning, branches et GitHub. Maîtrisez les bases et pratiques avancées du contrôle de code.
La question est rhétorique. Git est utilisé par à peu près tous les développeurs, data scientists, ingénieurs DevOps et même de plus en plus de profils data analystes. Et pourtant, dans la grande majorité des équipes, l’usage réel se limite à add-commit-push, avec un GitHub Desktop ou un IDE qui cache la machinerie. Le jour où le merge dérape, où l’historique part en spaghetti, où il faut faire un cherry-pick sur une branche oubliée, ou où un collègue rebase sur main alors que vous travaillez dessus, l’absence de modèle mental clair de Git coûte cher.
Une formation Git bien structurée n’est pas un luxe pour développeurs seniors. C’est un investissement court (quelques jours) qui paye sur toute la vie professionnelle d’un profil tech. Comprendre le modèle de Git (objets, références, index, working tree) suffit à débloquer la grande majorité des situations complexes.
Git – Fondamentaux est notre formation cœur Git. Elle couvre : modèle de données Git (objets, références, refs, index), commandes essentielles (init, clone, add, commit, status, log, diff), branches et merges, rebase (et quand le préférer au merge), gestion des conflits, tags et releases, distant remote (push, pull, fetch), workflows usuels (GitFlow, GitHub Flow, Trunk-Based Development), gestion des erreurs (reset, revert, reflog), stash, cherry-pick, bisect, et premières notions de hooks. La formation est calibrée pour passer d’un usage « add-commit-push aveugle » à une vraie maîtrise opérationnelle.
GitFlow propose un modèle structuré avec branches develop, feature/*, release/*, hotfix/* et main. Il convient aux organisations qui font des releases planifiées et qui ont besoin d’isoler les phases de stabilisation. C’est encore le workflow dominant dans la finance, l’embarqué et certaines applications enterprise. Le coût est une certaine lourdeur.
GitHub Flow simplifie en une seule règle : main est toujours déployable, on travaille sur des branches feature, on merge via Pull Request. C’est le workflow par défaut pour la majorité des projets open source et des scale-ups. Idéal en flux continu, déploiement fréquent.
TBD pousse plus loin : tout le monde travaille sur main (ou des branches très courtes de moins d’un jour), avec feature flags pour cacher les fonctionnalités non terminées. Beaucoup utilisé chez Google, Meta, Netflix, c’est la voie privilégiée pour les équipes qui veulent un CI/CD très rapide.
Notre formation aborde les trois workflows et aide à choisir selon votre contexte (taille d’équipe, fréquence de release, maturité CI/CD). Il n’y a pas de bonne réponse universelle.
Git s’inscrit dans un ensemble plus large couvert par notre catalogue. Le sous-domaine outils de développement logiciel regroupe nos formations sur les outils transverses. Le sous-domaine CI/CD couvre les pipelines d’intégration et déploiement continus qui s’appuient sur Git. Pour les équipes DevOps, le cross avec les sous-domaines DevOps et conteneurs est systématique.
Côté éditeurs, vous trouverez GitLab pour la plateforme DevOps complète, GitHub Copilot pour l’assistant IA de développement intégré à GitHub, et Open Source qui regroupe les technologies libres dont Git.
Git 2.45 et suivantes consolident les fonctionnalités côté monorepo (partial clone, sparse checkout), améliorent les performances sur les très gros repositories et finalisent SHA-256 (transition progressive depuis SHA-1). Côté plateformes, GitHub, GitLab et Bitbucket continuent leur consolidation. Côté IA, GitHub Copilot et les assistants IA intégrés à l’IDE génèrent une part croissante du code, ce qui change le rapport au commit (commit plus petits, plus explicatifs, plus revues humaines). Les workflows par PR/MR se généralisent partout.
Rebase ou merge sur une feature branch à fusionner sur main ?
Les deux ont leur place. Rebase produit un historique linéaire, plus lisible, à favoriser sur les branches feature courtes avant merge final. Merge avec –no-ff garde la trace de la branche, utile pour les features importantes. La règle d’or : ne jamais rebase une branche déjà partagée et publiée, sauf à coordonner avec toute l’équipe. Notre formation couvre ces cas en pratique.
Comment récupérer un commit perdu après un reset –hard ?
git reflog est votre ami. Le reflog garde la trace de tous les mouvements de HEAD pendant 90 jours par défaut, même les commits « perdus » après un reset –hard ou un rebase mal négocié. Vous retrouvez le SHA du commit perdu et vous le recheckoutez. C’est l’un des sujets qui rassure le plus en formation : Git pardonne plus que ce qu’on croit.
Cherry-pick d’un fix d’urgence depuis main vers une branche release : bonnes pratiques ?
Le cherry-pick reste l’outil approprié pour porter un commit isolé entre branches. Le piège classique est la dérive si plusieurs cherry-picks s’accumulent (les SHA divergent, les diffs deviennent confus). La discipline : limiter aux fix d’urgence, marquer le commit cherry-pické avec un message clair, et synchroniser dès que possible la branche release avec main.
Quelle stratégie pour les monorepos de plusieurs gigas ?
Git supporte les très gros repos avec partial clone, sparse checkout et plus récemment Scalar (intégré côté Microsoft pour Windows et VFS). Pour les monorepos extrêmes (type Google, Meta), des solutions complémentaires existent (Bazel, Buck, Nx). Notre formation aborde les bonnes pratiques pour les monorepos d’entreprise typiques en Suisse romande.
Faut-il commit dans .gitignore les fichiers de configuration locaux ?
Règle générale : non. Les secrets (.env, mots de passe, clés API) doivent être hors du repo et fournis par variables d’environnement ou secret manager. Les configurations locales (.vscode.idea) sont parfois ignorées, parfois commit selon la convention d’équipe. La discipline initiale économise des heures de débogage.
À l’issue de la formation, vous repartez avec un modèle mental clair de Git (objets, refs, index, working tree), des réflexes opérationnels sur les commandes essentielles, une compréhension des trois workflows majeurs (GitFlow, GitHub Flow, Trunk-Based) et la capacité de choisir le bon selon votre contexte, des techniques de récupération en cas d’erreur (reflog, reset, revert, cherry-pick), et une posture professionnelle de commit (messages clairs, taille raisonnable, séparation des préoccupations).
Sur le plan opérationnel, vous gagnez en autonomie face aux situations « Git en panique » qui font perdre du temps à toute l’équipe : conflit complexe, historique cassé, branche perdue, merge raté. Cette autonomie a une valeur immédiate pour vous et pour les collègues que vous n’avez plus besoin de solliciter à chaque incident.
Nos sessions Git sont disponibles à Genève, Lausanne et en classe virtuelle interactive avec un développeur en activité comme formateur. Pour les équipes qui veulent harmoniser leur pratique Git (par exemple à l’occasion d’un changement de plateforme GitLab vers GitHub, ou d’un changement de workflow GitFlow vers GitHub Flow), l’intra-entreprise permet de travailler directement sur votre convention d’équipe et vos repositories types.
L’usage individuel de Git est une chose ; l’usage en équipe est un sujet à part entière. Nos formations Git abordent les conventions qui structurent une équipe productive. Convention de messages de commit : un format clair (Conventional Commits par exemple : feat:, fix:, docs:, refactor:) permet de générer automatiquement les changelogs, de filtrer les commits par type et d’améliorer la lisibilité de l’historique. La discipline collective sur ce sujet a une vraie valeur sur la maintenance long terme du projet.
Convention de branches : main pour la production, develop pour l’intégration (en GitFlow), feature avec identifiant ticket et nom court pour les features, hotfix pour les corrections urgentes. Les conventions facilitent la lecture du dépôt et automatisent les hooks CI/CD. Convention de revue de code via Pull Request ou Merge Request : qui review, en combien de temps, quels critères de validation, comment gérer les conflits de point de vue. Nos formations abordent ces sujets, qui dépassent l’outillage technique mais conditionnent la productivité réelle d’une équipe.
Côté CI/CD, Git est au cœur des pipelines modernes. Chaque push déclenche des hooks (lint, tests unitaires, build, déploiement vers staging) selon la configuration. La maîtrise de Git facilite la lecture et le debug des pipelines CI/CD quand un job échoue de manière inattendue (mauvaise branche, conflit non résolu, tag manquant). Nos formations abordent cette intersection Git × CI/CD en présentant les patterns usuels sur GitHub Actions, GitLab CI et Bitbucket Pipelines.
ITTA
Route des jeunes 35
1227 Carouge, Suisse
ITTA
Route des jeunes 35
1227 Carouge, Suisse
