Django et git (git « pur », pas « github »)
Si jamais vous décidez d’être un vrai guerrier, un de ceux qui veulent tout maîtriser, un de ceux qui, quand on leur donne des ordres, peuvent les refuser (oui c’est rare), et si vous voulez prendre des responsabilités, bref, si vous en avez : faites vous votre propre serveur git !
Je ne décrirai pas comment installer un serveur git sous Linux tellement c’est simple. Et je ne décrirai pas non plus comment faire ça sous Windows : pour des raisons de sécurité, de fiabilité et d’éthique, évitez Windows un point c’est tout.
Donc, sous Linux :
- Créez un dossier dans lequel vous mettez toutes vos sources (
scp
est votre ami si vous êtes sur un PC et que vous voulez faire cela sur un autre PC) - Supposons que l’on est dans
/web/htdocs/interro/htdocs
- Créez un fichier
.gitignore
- Dans ce fichier, mettez ceci :
*.pyc
__pycache__
myvenv
db.sqlite3
/static
.DS_Store
Cela signifie « ignore tous ces fichiers (.DS_Store
est pour les personnes sous Mac (non je ne vous en veux pas, je suppose que vous ne connaissez pas bien l’histoire de l’informatique pour avoir acheté Apple)) » pour toutes les personnes qui vont cloner ce dossier - Ensuite, ajoutez tous les fichiers ainsi :
git add --all .
- Et commitez (oui je sais ce n’est pas français) ou « appliquez » les modifications c’est à dire l’ajout de tous les fichiers ainsi :
git commit -m "My application, first commit"
- Vous devriez avoir un paquet de fichiers ajoutés, vérifiez que tout est bien enregistré en demandant l’état via
git status
. Vous devez avoir un messsage ressemblant fortement à
nothing to commit (working directory clean)
- Vous êtes prêts ! Vous avez crée un repository (j’ai la flemme de traduire en français), et vous y avez appliqué tous vos fichiers. Il ne vous reste plus qu’à le cloner à distance
- (Update) : par défaut, le serveur travaille sur la branche d’origine (« master »). Seul problème : si vous essayez de faire un « push » à partir de votre PC de développement, git ne sera pas d’accord pour faire un « push » sur la branche « master ». Je pense que c’est pour des raisons de sécurité ou autre, mais c’est plutôt récent, avant cela fonctionnait. La solution : dites sur le serveur de travailler sur une autre branche c’est via l’ordre checkout. Notez bien : c’est sur le serveur. Je ne trouve pas ça très cohérent, j’aurais dit que c’était au client de dire sur quelle branche il veut « push », mais je dois manquer quelque chose… j’ai vraiment beaucoup de lacunes git. Bref. Exemple :
git checkout -b development
. - Ensuite il vous suffira de faire un
git clone
(dans PyCharm, c’est le menuVCS » git » clone
)
Bien sûr, comme tous les gestionnaires de version délocalisés, il vous faudra toujours trois étapes pour valider vos modifications :
- Appliquer les modifications en local (
git commit -m "mon message expliquant les modifs"
) - Essayer de récupérer toutes les dernières modifications du repository (
git pull
) vers votre code « local », au cas où d’autres personnes auraient « pushé » des modifications - Envoyer vos modifications sur le serveur pour qu’elles soient accessibles à tout le monde (
git push
)