Git pour des sites avec peu de développement

Bonjour
Je suis toujours au stade du versioning "manuel" c'est à dire que je copie mes fichiers html/php/css et leur donne leur attribut une suffixe genre #1, #2.... bref j'en suis encore à la préhistoire.
Je me penche donc ces derniers jours sur les solutions plus abouties et notamment sur Git et mes premiers contacts avec ce système me laissent un peu perplexe.

Pour faire simple, est-ce que ça vaut le coup de se plonger dedans (avec au passage se mettre à la ligne de commande) pour faire de "simples" versioning de projets/sites/fichiers html, css et php (mais dans ce cas du php qui reste très simple et peu complexe).

Merci pour vos éclairages.

Bonjour,

qu'est ce qui te déplait dans GIT ?

Personnellement je pense que l'intérêt, pour du travail en solo, réside surtout dans le fait d'avoir toujours une copie propre et à jour en local et donc une backup en cas de besoin + le fait de ne pas avoir a transférer tout le site pour appliquer des modifs.

Le versioning je n'en fais jamais mais ce serait sûrement plus simple pour toi avec un outil comme Git. Et je pense que tu peux trouver des logiciels ou plugins pour ton éditeur de code si tu ne souhaite pas taper directement les commandes.

Je ne peux pas dire qu'il y a quelque chose qui me déplait. Mais je trouve les tutos dispo peu facilement accessibles. Et avant de m'y plonger je voudrai être sur que ça vaut le coup.

Bonjour,

Quelque soit l'outil de versioning, ça ne vaut le coup selon moi que si tu fais souvent des mises à jour (au minimum plusieurs fois par mois si ce n'est par semaine). Sinon, tu t'épuises à faire marcher ton outil, et à le maintenir lui-même à jour. Au bout de deux ou trois mois sans toucher à un projet, t'es quasi sûr de ne plus te souvenir de ce qui est (vraiment) à jour et de ce qui ne l'est pas, de ce qui est en test ou pas, et tu es toujours en train de te demander si tu dois garder ou pas ta copie en local, ou éventuellement l'écraser avec ce qui est en ligne, ou si tu peux vraiment mettre en ligne ce qui est en local. En fin de compte, t'as toujours les mêmes problèmes que si tu gères ton source à l'ancienne.

Si par contre tu fais souvent des mises à jour, et si tu ne laisses jamais un truc important pas fini en local, c'est quand même bien pratique de pouvoir mettre à jour la version en ligne (ou remettre à jour la version en local) en ayant à télécharger que ce qui est différent, et sans qu'il y ait d'oubli.

La question de la sauvegarde est à part : il existe des solutions qui marchent toutes seules sans avoir à passer par un outil de versioning (et qui au passage sont capables de sauvegarder tout ce qui est sur ta machine, pas seulement tes sites web). Sous Mac OS par exemple, t'as en gros 2 clics à faire et ça ronronne sans que tu t'en occupes pendant des années.

Bref, en résumé, ça vaut le coup si tu es un utilisateur régulier.

Amicalement,

Perso, je travaille sur mon code tous les soirs et les week ends, autant dire qu'il évolue quasi en permanence.
Pourtant je n'utilise aucun gestionnaire de source, que ce soit GIT, SVN ou autre.
Ayant essayé ces solutions, elles se sont révélées finalement trop lourdes et je n'ai pas besoin d'un suivi de version pointilleux permettant d'extraire un fichier ayant tel numéro d'ancienneté.
Finalement, la solution la plus simple et la plus efficace à l'usage (mon EDI étant Eclipse) a été tout simplement de faire un export complet de mon projet à chaque fin de session de travail, vers un répertoire disque que je numérote séquentiellement (ex. Thot_001, Thot_002, etc...).
Etant rendu à ce jour au 122, ce mode de fonctionnement me convient parfaitement.
C'est simple et surtout je dispose d'une image compacte du projet à un instant T.
Si je dois réimporter une version antérieure dans son état, il me suffit de reprendre la totalité du répertoire en question et le restaurer sous Eclipse.
Pas de fichier supplémentaire stockant les numéros de version dans les sous répertoires, comme sous SVN.
Quant à la récupération d'un fichier pour restaurer une méthode ancienne, une simple recopie vers Eclipse est là aussi suffisante.
La méthode peut paraître "bourrin" mais elle est efficace pour couvrir mon besoin et c'est tout ce que je lui demande.

Git représente un peu plus d'intérêt que cela. Le cantonner à un rôle de backup journalier le rendrait en effet limité.

Beaucoup de personnes peuvent très bien se débrouiller sans, surtout en travaillant sur un seul projet et tout seul. En gérant "à la main" des copies, des numérotations, de l'archivage à distance, etc.

Si je peux faire un parallèle un peu rapide, ce serait comme coder un site avec le bloc-notes (on le peut tout à fait) alors qu'on peut se servir d'outils plus évolués et qui - avec l'habitude - se révèlent plus pratiques.

Je vois entre autres comme fonctionnalités importantes :
- synchronisation avec serveur distant (pour mettre en ligne ou "sauvegarder")
- pouvoir travailler temporairement sur des fonctionnalités et les mettre de côté en attendant
- gérer plusieurs "versions" (branches) en parallèle d'un même code
- pouvoir récupérer des versions précises (pas d'après la date qui reste floue - quand ai-je fait ceci, cela - mais d'après un tag qu'on aura renseigné)
- avoir un historique "propre" de ce qui a été réalisé
- très rapide pour toutes ces opérations

Git n'est pas facile à aborder, mais il rend bien des services.
À plusieurs il me semble indispensable.

dew a écrit :
Git représente un peu plus d'intérêt que cela. Le cantonner à un rôle de backup journalier le rendrait en effet limité.

Tout à fait exact, et dans mon boulot au bureau, nous utilisons des gestionnaires de sources, que ce soit SVN ou TFS puisque, par définition, nous fonctionnons en équipes.
A priori, la question initiale me paraissait toutefois être plutôt dans un contexte de développement en autonome.
Juste pour compléter les infos, l'utilisation d'un gestionnaire de sources pour un volume de données important peut avoir un effet pervers... le jour où un quidam décide que dorénavant ce ne sera plus l'outil X mais l'outil Y qu'on utilisera.
Pour avoir vu les problèmes de migrations soulevés au bureau justement, et les sueurs froides de certains managers lorsque la direction commence à leur demander pourquoi tout est bloqué ou très long, c'est un aspect qu'il ne faut pas oublier trop vite.