Initialiser git sur un projet django préexistant

Bonjour,

je dois initialiser git sur un projet Django déjà existant. Ce projet a été devéloppé par une seule personne à l'origine, mais a pris beaucoup d'ampleur et d'autres développeurs vont se joindre au projet, d'où la création d'un git.
Le projet est sur un réseau hors ligne, sur un serveur déjà accessible par SSH. Ma question est, quelle est la meilleure méthode d'initialisation entre :
- Créer un nouveau dossier django.git dans lequel j'execute un git init --bare, puis push le projet du serveur sur ce repository, et enfin clone le repository sur les ordi des devs. Dans cette option, on est d'accord que je vais devoir git pull sur le projet existant pour afficher les mises à jour des développeurs ?
- Initialiser le repository directement dans le dossier existant, mais j'ai essayé j'ai des problèmes de push quand la branche sur le serveur est sur master. J'ai pas l'impression que c'est la bonne méthode.

J'ai déjà effectué des recherches mais n'ait pas vraiment trouvé, d'où ma demande ici. Je précise que je suis un débutant de git, je connais les commande de bases mais pas vraiment la bonne architecture ou la bonne façon de faire.

Je vous remercie d'avance pour vos retours éclairés.

Bonjour,

Oui, la manière normale de faire (même si ce n'est pas forcément toujours le cas car Git est « acentralisé ») est bien d'avoir un serveur, si possible --bare pour bien montrer que c'est un serveur et éviter que quelqu'un travaille directement dans le dépôt officiel, puis une copie locale par développeur référençant le serveur en branche amont (automatique avec git clone).

Ça veut dire que dans ton cas, il faudrait faire les deux : commencer par transformer le répertoire officiel des sources en dépôt Git avec un git init normal, puis pousser ce dépôt vers un serveur qu'on aura pris soin d'initialiser au préalable et de renseigner comme dépôt distant (« remote »).

Toutefois, je comprends ici qu'il s'agit d'un projet DJANGO et donc web. Ça veut dire que le développeur devait travailler directement dans le dépôt du serveur web et voir ses modifications immédiatement en ligne quand il développait (j'ai le même problème ici).

En ce sens, créer un serveur non-bare dont le répertoire de travail serait en fait directement le dépôt du serveur web ne sera pas d'un grand secours car Git, dans un premier temps, refusera tous les push à destination du serveur si la branche ciblée est en vigueur (check out) dans le dépôt concerné. Ce qui se comprend : il ne va pas aller automatiquement modifier les fichiers si quelqu'un est potentiellement en train de travailler dessus. Il est possible de configurer receive.denyCurrentBranch pour demander au serveur d'accepter les soumissions quand même mais même ainsi, cela ne mettra pas à jour le répertoire de travail. Et comme il y manquera des fichiers par rapport à la branche tout juste mise à jour, ceux-ci seront interprétés comme « supprimés » par git status.

En revanche, il est possible de mettre des hooks sur le serveur pour déclencher des opérations lorsque Git reçoit des soumissions, et tu peux utiliser ces hooks pour mettre automatiquement le dépôt web à jour. Pour ce faire, tu peux par exemple utiliser git archive si tu veux facilement récupérer le contenu d'une version donnée sans trop impacter l'état des branches locales, ou tu peux définir la variable d'environnement GIT_WORK_TREE qui te permet de spécifier un répertoire de travail donné, qui pour le coup n'est pas forcément celui qui contient .git. Et l'avantage, c'est que dans ce cas, ça fonctionne aussi avec les dépôts bare.

Super réponse, je vais tester ce système avec les hooks que je ne connaissais pas.
Si j'ai bien compris, je monte un repository bare, je push mon projet dedans et je met un hook au niveau du repository qui dès lors qu'il reçoit un push, va push les modification dans mon projet ?

Merci en tout cas de ta réponse rapide !

Citation:

---

Envoyé par Al PiGiNo

Super réponse, je vais tester ce système avec les hooks que je ne connaissais pas.
Si j'ai bien compris, je monte un repository bare,

---

Oui, sur ton serveur.

Citation:

---

je push mon projet dedans

---

Oui, mais pour pouvoir le pousser sur le serveur, il faut que ton dépôt local soit déjà un dépôt Git. Donc, il faudra l'initialiser d'abord, en non-bare de ce côté-là.

Citation:

---

et je met un hook au niveau du repository qui dès lors qu'il reçoit un push,

---

Oui, côté serveur là encore…

Citation:

---

va push les modification dans mon projet ?

---

Non pas tout-à-fait (ou alors les termes sont mal choisis). À ce stade, l'état de ton projet est déjà dans le dépôt officiel côté serveur. Tu vas en fait demander au serveur de déployer automatiquement les fichiers reçus vers le répertoire du serveur web pour qu'ils apparaissent directement en ligne. C'est un push au sens large mais pas pour Git.

À noter que ce n'est pas miraculeux non plus, mais le reste est politique : il va falloir que tu choisisses si tu veux mettre le dépôt web à jour quelque soit la soumission reçue ou si on ne doit le faire que lorsque c'est une branche spécifique qui est mise à jour (master par exemple). Et dans tous les cas, elles ne seront visibles que lorsque le développeur aura commité ses changements et les aura poussés en ligne. Donc le mieux reste quand même d'avoir chacun son propre serveur web local pour travailler, lorsque c'est possible.

Et si ça ne l'est pas, alors il faudra travailler directement sur le serveur web et dans ce cas, cela devra être un clone non-bare comme on le ferait sur son poste de travail. Il faudra ensuite mettre des conditions d'accès pour éviter que les devs se marchent sur les pieds. On perd l'un des principaux intérêts de Git, mais on conserve le versioning, qui reste le principal.

Et bien sûr, c'est toujours une bonne idée de mettre tous les dépôts officiels (les bare) sur une machine qui soit backupée automatiquement.