Collaboration avec GitHub-GitLab

GitHub vs GitLab : différences principales

Les deux plateformes sont construites autour de Git et offrent des fonctionnalités similaires.

Similarités :

• Gestion de repositories Git
• Revue de code (Pull/Merge Requests)
• Issues et project boards
• Wiki et documentation
• API complètes

Créer un compte

GitHub

1. Allez sur github.com
2. Cliquez sur "Sign up"
3. Entrez email, mot de passe, nom d'utilisateur
4. Vérifiez votre email
5. Choisissez le plan gratuit

GitLab

1. Allez sur gitlab.com
2. Cliquez sur "Register"
3. Entrez nom, nom d'utilisateur, email, mot de passe
4. Vérifiez votre email

Créer un repository distant

Sur GitHub

1. Connectez-vous à GitHub
2. Cliquez sur le bouton "+" en haut à droite → "New repository"
3. Remplissez les informations :
   • Repository name : nom du projet
   • Description : (optionnel) description courte
   • Public/Private : visibilité du repo
   • Initialize repository : cochez "Add a README file" si nouveau projet
4. Cliquez sur "Create repository"

Sur GitLab

1. Connectez-vous à GitLab
2. Cliquez sur "New project" → "Create blank project"
3. Remplissez :
   • Project name
   • Visibility Level (Private/Internal/Public)
   • Cochez "Initialize repository with a README" si nécessaire
4. Cliquez sur "Create project"

Lier un repository local à un remote

Ajouter un remote

# Voir les remotes configurés
git remote -v
 
# Ajouter un remote nommé 'origin'
git remote add origin https://github.com/username/mon-projet.git
 
# Pour GitLab
git remote add origin https://gitlab.com/username/mon-projet.git

Vérifier :

git remote -v

Sortie :

origin  https://github.com/username/mon-projet.git (fetch)
origin  https://github.com/username/mon-projet.git (push)

Renommer un remote

git remote rename origin nouveau-nom

Supprimer un remote

git remote remove origin

Push : envoyer vos commits

git push

Envoie vos commits locaux vers le repository distant.

# Premier push : définir le remote par défaut
git push -u origin main
 
# Pushs suivants
git push

Explication :

• -u (ou --set-upstream) : définit origin main comme branche de suivi par défaut
• origin : nom du remote
• main : nom de la branche

Push d'une nouvelle branche

git switch -c feature/nouvelle-feature
git add .
git commit -m "feat: nouvelle fonctionnalité"
git push -u origin feature/nouvelle-feature

Forcer un push (⚠️ dangereux)

git push --force
# ou version plus sûre
git push --force-with-lease

Pull : récupérer les modifications

git pull

Récupère et fusionne les changements du remote.

# Récupérer les changements de la branche actuelle
git pull
 
# Équivalent à :
git fetch
git merge origin/main

git fetch

Télécharge les changements sans les fusionner.

# Télécharger tous les changements
git fetch
 
# Télécharger d'un remote spécifique
git fetch origin
 
# Voir les changements téléchargés
git log main..origin/main

Workflow recommandé :

# 1. Télécharger les changements
git fetch
 
# 2. Voir les différences
git log main..origin/main
git diff main origin/main
 
# 3. Fusionner si tout est ok
git merge origin/main

Cloner un repository existant

git clone

Télécharge une copie complète d'un repository distant.

# Cloner via HTTPS
git clone https://github.com/username/projet.git
 
# Cloner via SSH (nécessite configuration SSH)
git clone git@github.com:username/projet.git
 
# Cloner dans un dossier spécifique
git clone https://github.com/username/projet.git mon-dossier
 
# Cloner uniquement la branche main
git clone --single-branch --branch main https://github.com/username/projet.git

Authentification

HTTPS (recommandé pour débuter)

GitHub : utilise un Personal Access Token depuis 2021 (plus de mot de passe).

Créer un token :

1. GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic)
2. Generate new token
3. Sélectionnez les permissions (repo, workflow, etc.)
4. Copiez le token (vous ne le reverrez plus !)

Utilisation : Lors du premier git push, entrez votre token à la place du mot de passe.

GitLab : similaire, via Settings → Access Tokens.

SSH (recommandé pour utilisation régulière)

Avantages : pas besoin de saisir token/mot de passe à chaque fois.

Configuration :

1. Générer une clé SSH :

ssh-keygen -t ed25519 -C "votre.email@example.com"

Appuyez sur Entrée pour accepter l'emplacement par défaut (~/.ssh/id_ed25519).

2. Copier la clé publique :

# Linux / macOS
cat ~/.ssh/id_ed25519.pub
 
# Windows
type %USERPROFILE%\.ssh\id_ed25519.pub

3. Ajouter la clé sur GitHub/GitLab :

   • GitHub : Settings → SSH and GPG keys → New SSH key
   • GitLab : Settings → SSH Keys
   • Collez la clé publique

4. Tester la connexion :

# GitHub
ssh -T git@github.com
 
# GitLab
ssh -T git@gitlab.com

5. Utiliser SSH pour clone/push :

git clone git@github.com:username/projet.git

Pull Requests (GitHub) / Merge Requests (GitLab)

Pull Request (PR) sur GitHub ou Merge Request (MR) sur GitLab : demande de fusion d'une branche dans une autre, avec revue de code.

Créer une Pull Request sur GitHub

Workflow complet :

1. Créer une branche :

git switch -c feature/nouvelle-fonctionnalite

2. Développer et committer :

git add .
git commit -m "feat: ajout fonctionnalité X"

3. Pusher la branche :

git push -u origin feature/nouvelle-fonctionnalite

4. Créer la PR sur GitHub :

   • GitHub affichera un bouton "Compare & pull request"
   • Ou allez dans l'onglet "Pull requests" → "New pull request"
   • Sélectionnez la branche source et destination
   • Ajoutez un titre et une description
   • Assignez des reviewers (optionnel)
   • Cliquez sur "Create pull request"

5. Revue et merge :

   • Les reviewers examinent le code
   • Discussion et modifications si nécessaire
   • Une fois approuvée, cliquez sur "Merge pull request"

Créer une Merge Request sur GitLab

Processus similaire :

1. Pusher la branche
2. GitLab affiche "Create merge request"
3. Remplir le formulaire (titre, description, assigné)
4. Définir si suppression automatique de la branche après merge
5. Créer la MR

Forker un repository

Fork : créer une copie d'un repository dans votre compte pour y contribuer.

Workflow de contribution open-source

1. Forker le projet :

   • Cliquez sur "Fork" sur GitHub/GitLab
   • Le repo est copié dans votre compte

2. Cloner votre fork :

git clone https://github.com/VOTRE-USERNAME/projet.git
cd projet

3. Ajouter le repo original comme remote "upstream" :

git remote add upstream https://github.com/AUTEUR-ORIGINAL/projet.git
git remote -v

4. Créer une branche pour votre contribution :

git switch -c fix/correction-bug

5. Développer et committer :

git add .
git commit -m "fix: correction du bug X"

6. Pusher sur votre fork :

git push origin fix/correction-bug

7. Créer une Pull Request :

   • Depuis votre fork sur GitHub
   • Cliquez "Contribute" → "Open pull request"
   • La PR est envoyée au repo original

8. Garder votre fork à jour :

# Récupérer les changements du repo original
git fetch upstream
git switch main
git merge upstream/main
git push origin main

Collaborer en équipe

Ajouter des collaborateurs

GitHub :

1. Settings du repo → Collaborators → Add people
2. Entrez le nom d'utilisateur ou email
3. L'utilisateur reçoit une invitation

GitLab :

1. Project → Members → Invite members
2. Choisissez le niveau d'accès (Developer, Maintainer, etc.)

Protéger la branche main

Bonnes pratiques :

• Empêcher les pushs directs sur main
• Exiger des Pull Requests
• Exiger des revues de code
• Exiger que les tests passent (CI)

GitHub : Settings → Branches → Add branch protection rule

GitLab : Settings → Repository → Protected branches

Issues et Project Management

Issues

Suivre les bugs, fonctionnalités, et tâches.

Créer une issue :

1. Onglet "Issues" → "New issue"
2. Titre et description
3. Labels (bug, enhancement, documentation, etc.)
4. Assignés, milestones

Lier commits et issues :

git commit -m "fix: correction du login (#42)"

Le #42 crée un lien automatique vers l'issue 42.

Fermer une issue via commit :

git commit -m "fix: problème résolu. Closes #42"

Projects

Tableaux Kanban pour organiser les tâches.

GitHub : Projects → New project (Table, Board, Roadmap)

GitLab : Issue boards intégré

GitHub Actions / GitLab CI (aperçu)

Automatisation (tests, déploiement) lors des pushs/PRs.

Exemple GitHub Actions (.github/workflows/test.yml) :

name: Tests
 
on: [push, pull_request]
 
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: npm test

Exemple GitLab CI (.gitlab-ci.yml) :

test:
  script:
    - npm install
    - npm test

Résumé des commandes

Bonnes pratiques de collaboration

Commits atomiques : un commit = un changement logique.

Messages clairs : suivre les conventions (feat, fix, docs, etc.).

Pull avant push : toujours récupérer les derniers changements avant de pusher.

Branches courtes : fusionner rapidement pour éviter les conflits.

Revue de code : toujours faire relire vos PRs.

Tests automatisés : configurer CI/CD pour valider automatiquement.

Documentation : README à jour, commentaires de code si nécessaire.

Liens vers la partie suivante

• 7. Workflows Git (intro simple)

Tags

#git #github #gitlab #collaboration #pullrequest #mergerequest #remote