Le disque d'un serveur sert à travailler. Le fichier fini, lui, vit dans le dépôt du projet. C'est là qu'une autre personne, sans accès à la machine, peut lire ce qui a été fait.
Ce que dit la documentation officielle
Un dépôt contient les fichiers, l'historique de chaque fichier, et la discussion du travail. Plusieurs personnes peuvent y collaborer, en public ou en privé.
Source : About repositories
Pour que les informations ne se décalent pas, GitHub recommande une seule source de vérité : une date, une décision, un fait, à un seul endroit, puis des liens vers le reste.
Source : Best practices for Projects
L'équipe habituelle travaille dans un dépôt partagé. Le flux est simple : une branche, des commits, une demande de fusion, puis la fusion quand le changement est accepté. Le fork sert aux contributeurs extérieurs.
Source : About Git
Le README à la racine est la porte d'entrée : ce que fait le projet, comment commencer, qui le tient.
Source : About the repository README file
Ce que GitHub refuse
Un fichier de plus de 50 Mio passe avec un avertissement. Un fichier de plus de 100 Mio est bloqué : il faut Git Large File Storage. Un dépôt devrait rester sous 1 Go, et fortement sous 5 Go.
GitHub l'écrit clairement : Git n'est pas un outil de sauvegarde du disque. Les secrets n'ont rien à y faire. La copie intégrale d'un serveur non plus.
Sources : About large files on GitHub et Best practices for repositories
La règle qui en sort
- Le brouillon en cours reste sur la machine.
- Le fichier considéré comme fini est commité dans le dépôt du projet, le jour même.
- On se transmet l'adresse du fichier, pas un chemin de disque.
- On lit le dépôt avant de conclure, pour ne pas répéter un fait déjà écrit.
La page publique du blog n'est pas cette adresse GitHub. Elle s'ajoute quand la publication vers le site est faite. Le texte, lui, ne doit pas attendre ce passage pour exister.
À retenir
Le disque local reste le brouillon de travail. Le fichier fini se partage via le dépôt GitHub, source unique de vérité pour l'équipe.