Bonjour tout le monde

Alors voilà, j'ai décidé de sauter le pas : l'utilisation d'un logiciel de versioning. On en voit tous les raisons diverses et variées, surtout que je collabore parfois avec un ami.

À la base, je développe du code HTML, CSS, PHP, un peu de JS et de SQL. Oui mais voilà, j'ai l'impression, en ayant passé ma journée à lire 2 tutos d'Open Classrooms, jeté quelques coups d'œil sur d'autres tutos web, regardé même des vidéos sur Yt sur le sujet, que Git est peut-être destiné à du développement de logiciels ou d'applications, et non pas de sites internet.

Maintenant, je peux clairement me tromper, bien entendu, et il est vrai que j'aimerais savoir comment des développeurs informatiques de langages de programmation web utilisent Git (et GitHub) ?

Car voici mon problème :

Habituellement, j'utilise Sublime Text pour coder, Total Commander en tant que lanceur FTP, les fichiers sont sur un serveur OVH, je les récupère, je modifie, je renvoie sur le serveur. En général, pour des améliorations conséquentes, je récupère le fichier du serveur (ex : contacts.php), je créé un "double" (contacts2.php), je fais tous mes changements dessus, car je peux l'uploader au fur et à mesure sur le serveur sans que les utilisateurs ne soient impactés, et une fois que tout me semble OK, je renomme "contacts2.php" en "contact.php", et je l'upload sur le serveur.

En tant que tel, c'est comme si je créais une "branche", et qu'à la fin, je "merge" la branche sur le "master".

Sauf que... bah au final, si j'ai bien compris, dans Git, mon fichier s’appellera toujours "contacts.php", ce qui fait que si je le modifie pour des tests en vue d'une amélioration, et que je l'envoie sur le serveur, ça risque d'impacter les utilisateurs actuellement présents sur la page, qui n'est qu'en développement.

Bref, j'ai du mal à comprendre comment utiliser intelligemment Git pour du développement web ? D'où ma question du dessus, peut-être que je n'utilise pas les bons outils pour coder, envoyer mes fichiers sur le serveur, etc. etc.

Je vous remercie pour votre attention ^_^

En général on va avoir une version de développement du site, et une version de production. La version de production est celle accessible au public, et l'autre juste aux devs.

C'est le même principe que ce que tu fais déjà, sauf qu'au lieu de pouvoir tester les fichiers un par un, tu peux tester le site entier. Tu peux par exemple créer un vhost /dev dans lequel tu déploie ta branche de développement.

L'intérêt c'est aussi de pouvoir avoir une base de données de développement, parce qu'avec ton système actuel, si ton code de développement fait crasher la base de données, ça va avoir un impact sur les clients du site.

EDIT : git et les autres outils de gestion de version sont autant adaptés au web qu'aux autres types de développement. D'ailleurs on peut même les utiliser pour n'importe quel format texte, comme pour écrire un livre par exemple.

-
Edité par LoupSolitaire 8 janvier 2020 à 19:08:02

LoupSolitaire a écrit:

L'intérêt c'est aussi de pouvoir avoir une base de données de développement, parce qu'avec ton système actuel, si ton code de développement fait crasher la base de données, ça va avoir un impact sur les clients du site.

-
Edité par LoupSolitaire il y a environ 15 heures

Eh oui, ça je ne l'avais pas indiqué, mais effectivement c'est un problème dont j'avais effectivement conscience... Merci pour ta réponse en tous cas

Donc oui, maintenant je vois le principe de créer une version de dev du site, et une version production. Et dans cette façon de travailer, les outils de gestion de version sont surtout utilisés sur les fichiers de la version dev, j'imagine... (?)

PS : LoupSolitaire, je plussoie ta signature ;p

Matth000 a écrit:

Donc oui, maintenant je vois le principe de créer une version de dev du site, et une version production. Et dans cette façon de travailer, les outils de gestion de version sont surtout utilisés sur les fichiers de la version dev, j'imagine... (?)

Les deux, puisque les versions de dev sont potentiellement les futures versions de production.

Matth000 a écrit:

PS : LoupSolitaire, je plussoie ta signature ;p

LoupSolitaire a écrit:

    Tu peux par exemple créer un vhost /dev dans lequel tu déploie ta branche de développement

Je reviens sur cette phrase, qui m'a intrigué et qui m'a pas occupé durant ces dernières 24 heures. Notamment le Vhost, que je ne connaissais pas. Du coup je me suis renseigné dessus, autant que possible, sauf que je n'ai rien trouvé de bien convaincant. Étant en hébergement mutualisé chez OVH, j'ai tenté de regardé dans leurs guides/tutoriels ce que je pouvais dénicher là dessus, mais le terme "Vhost" n'est surtout affilié qu'à des pages sur des offres relatives à la location de serveurs (et aux routages de ces derniers). (Pour info, le site dont je m'occupe est en hébergement mutualisé "Perso". Il n'est pas énorme, sachant qu'il s'agit juste de l'intranet d'une entreprise pour lequel 4 personnes max travaillent sur des fiches clients. La BDD est exploité à moitié, donc opter pour "plus", ce serait du gachis)

À part ça, les quelques autres sites de documentation rencontrés parlent d'installation de vhost sur des serveurs Apaches... Sauf que je n'ai pas accès au serveur d'OVH, bien évidemment

Y a t-il une solution logique pour les "petits" sites internet que d'installer un vhost ? Ou bien est-ce quand même possible (et à faire), mais du coup, par quel moyen ?

C'est peut-être pas utile pour toi en fait les Vhosts, tu peux juste créer un sous-dossier avec la version de développement, par exemple le site de production www.site.tld/ (normal) et le site de développement dans www.site.tld/dev/.

Les vhosts ça permet d'héberger plusieurs sites web sur le même serveur (avec la même adresse IP) avec un nom de domaine différent, mais en mettant le site de dev dans un sous-dossier, c'est pas utile puisque c'est le même nom de domaine.

Normalement avec la technique du sous-dossier, tu ne devrais pas avoir besoin de changer d'offre d'hébergement. Après ça fait un moment que j'ai pas fait de PHP (et donc aux hébergeurs PHP), donc je peux me tromper là dessus.