git pour des projets personnels (un homme). Surpuissance?

Je connais et utilise deux systèmes de contrôle de version: Subversion et git. Subversion, à partir de maintenant, est utilisé pour des projets personnels où je suis le seul développeur et git est utilisé pour des projets open source et des projets où, je pense, d'autres vont également travailler sur le projet. Ceci est principalement dû aux capacités étonnantes de git en matière de forking et de fusion, où chacun peut travailler sur sa propre branche; très utile.

Maintenant, j'utilise Subversion pour des projets personnels, car je pense que git n’a aucun sens. Cela semble être un peu excessif. Cela me convient si le système est centralisé (sur mon serveur domestique en général) lorsque je suis le seul développeur; Je fais des sauvegardes régulières quand même. Je n'ai pas besoin de la capacité de créer ma propre branche, la branche principale est ma branche. Oui, SVN a un support simple pour la création de branches, mais un support beaucoup plus puissant n’a aucun sens, je pense. La fusion peut être pénible, ou du moins d'après ma petite expérience.

Y a-t-il une bonne raison pour que j'utilise Git sur des projets personnels, ou est-ce tout simplement excessif?

Ce n'est pas exagéré. La principale raison pour laquelle j'ai commencé à utiliser Git et Mercurial par-dessus Subversion pour des projets personnels est qu'il est beaucoup plus facile de lancer un référentiel.

Voulez-vous démarrer un nouveau projet?

> git init

BAM! Il n'est pas nécessaire de configurer un serveur de référentiel ni d'archiver une structure de dossiers pour prendre en charge la création de branches et de balises dans un référentiel de sous-version.

Partager votre projet plus tard est juste une question de: git push(autre que d'avoir un référentiel distant). Essayez de le faire rapidement avec subversion!

Je soutiendrais qu'utiliser Subversion pour des projets personnels locaux est excessif, alors que Git ne l'est décidément pas. Git prendra moins de place (en raison du concept inefficace de "révisions" de SVN par rapport aux instantanés d'objet de Git), nécessite moins de configuration ( git initcomparé à une douzaine de svnadmincommandes et d'autorisations de configuration, etc.), est plus facile à sauvegarder ( git clone --bare[ou git push originsi vous utilisez Github ou similaire] et vous avez terminé), et dispose de meilleurs outils pour gérer votre code (la création de branches est gratuite, et la fusion est plus facile et plus propre). Ce n’est pas parce que personne n’a un clone de votre référentiel que les avantages de tout système DVCS sont "excessifs".

De plus, je dirais que le support des branches de Git est moins complexe que celui de SVN, avec de plus grandes récompenses.

Penser que vous ne créerez jamais votre propre code est un peu à courte vue. J'ai diversifié mon propre code plusieurs fois, en particulier lorsque j'essayais une nouvelle approche qui ne m'avait pas encore convaincu. Vous voudrez éventuellement la fonctionnalité.

Cela vient d'un utilisateur de longue date de Subversion. La consolidation sur un seul outil peut réellement vous faciliter la vie.

Le surmenage est réservé aux dommages collatéraux causés par la "solution". Utiliser une arme à feu pour tuer une mouche signifie qu'il y a des dommages causés par la balle qui va ailleurs. C'est exagéré. Utiliser quelque chose de plus puissant que nécessaire qui ne cause pas de problème n'est pas excessif et peut être une bonne chose si cela vous aide à rationaliser votre processus de développement. Cela ne cause aucun préjudice et vous permet de n'avoir à mettre à jour qu'un ensemble de logiciels au lieu de deux. Alors pourquoi s'embêter avec deux systèmes au lieu d'un?

J'utilise Git pour mes projets solo et j'adore ça. J'utilisais auparavant Subversion et je n'ai pas encore vu d'inconvénient à utiliser Git. C'est plus puissant, mais pas d'une manière qui rend les choses simples plus compliquées. Rendre des choses simples inutilement compliquées / coûteuses / lentes / etc. IMHO est une condition nécessaire pour appeler quelque chose de trop. De plus, sur Github, j’ai demandé à des personnes qui avaient précédemment participé à des projets uniques d’ajouter une fonctionnalité que je voulais, puis je leur ai envoyé des demandes de tirage. Je trouverais ça plutôt cool que quelqu'un qui s'intéresse à mes projets fasse la même chose.

Je n’avais jamais utilisé le contrôle de la source sur des projets personnels avant DVCS. C’est donc un peu étrange d’imaginer quelqu'un qui prend le point de vue opposé. Certaines de mes raisons sont:

• Facile à installer et à démonter. Par exemple, un collègue m'a offert un casse-tête de programmation la semaine dernière, que j'ai résolu en plusieurs étapes. J'ai fait un dépôt git qui a duré toutes les 45 minutes pour tenir mon travail, puis il était parti. Je ne sais pas à quel point une telle chose est facile dans la subversion, mais je n'ai jamais entendu dire que quelqu'un le fasse.
• Débranché. Pour moi, le fait de pouvoir travailler hors connexion est beaucoup plus avantageux pour un projet de loisir que pour un projet professionnel. Je n'ai pas besoin de percer le pare-feu de ma maison ou d'héberger un projet en public. Je peux mettre temporairement un repo sur une clé USB ou un ordinateur portable, tout en maintenant la synchronisation.
• Tout colo. La combinaison du référentiel et de l'arborescence de travail facilite la tâche de suivi de petits projets lors de mises à niveau de systèmes d'exploitation.
• Caractéristiques puissantes. Bien sûr, je n’ai pas besoin de l’alimentation tout le temps, mais c’est là quand j’en ai besoin, et ne consomme aucune ressource quand j’en ai pas.

On m'a dit que git-bisectc'est vraiment bien de trouver le commit exact qui a introduit un comportement donné, en naviguant dans les commits en fonction de votre contribution.

Vous devrez le faire un jour pour des choses que vous ne pouvez tout simplement pas comprendre.

EDIT: De plus, la capacité de créer des branches est très importante lorsque vous devez corriger des corrections de bugs dans les anciennes versions utilisées par les clients. Vous devez être capable de gérer "corrigez simplement cette petite chose mais je ne veux pas de la version la plus récente car je ne veux pas la tester à nouveau maintenant".

Cela dépend de la gravité de la mise à jour de votre propre code. Si ce que vous construisez est par exemple une simple bibliothèque qui n’aura que la version actuelle (ou tant que cela sera vrai), j’utiliserais personnellement une option de sauvegarde de base telle que Dropbox. Si vous perdez tout votre code, vous pouvez le récupérer sur le Web. Dropbox dispose d’une sauvegarde de la version 30 jours si vous faites vraiment quelque chose de stupide.

Cependant, si vous avez par exemple besoin de maintenir des branches Production et Dev, alors git est un excellent outil - et bien plus rapide que svn. Attention toutefois au risque de défaillance du disque dur si vous ne stockez que les données localement.

J'utilisais toujours, toujours, toujours un système de contrôle de version pour tout type de projet de développement. Grand ou petit n'a pas d'importance. Que je joue à la maison avec une nouvelle technologie, que je rédige un petit numéro d'aide pour me simplifier la vie ou que je développe professionnellement au sein d'une grande équipe distribuée, je voudrais toujours un système de contrôle de version pour me sauvegarder.

Bien sûr, la plupart du temps, pour les petits projets personnels, vous n’utiliserez pas la plupart des fonctionnalités, mais la configuration d’un référentiel git (ou même d’un référentiel Subversion local) n’a rien de grave, allez-y! Et avant de vous en rendre compte, vous voudrez savoir "bon sang, quel était le contenu du fichier X vendredi dernier?". Sans contrôle de version - bonne chance ;-)

Donc, peu importe que vous utilisiez git ou SVN - personnellement, je commence à migrer de plus en plus de choses de SVN vers git, mais l'essentiel est d'utiliser le contrôle de version, même pour les petites choses.

Seulement parce que personne ne l’a mentionné: pour les projets personnels, darcs est vraiment bon et moins impliqué que git pour faire du contrôle de version simple. Ce n'est pas aussi rapide pour les grands projets, mais Subversion non plus!

Comprendre que ce que nous faisons est de l’expérimentation peut être un puissant changement de paradigme mental. Avoir un outil simple et peu coûteux pour supporter cela améliore votre capacité à avancer, en partie parce qu’il améliore votre capacité à annuler toute expérience quand elle se révèle médiocre.

De nombreux développeurs disent: «Je ne fais que des copies de mon code. Mais ces copies deviennent difficiles à gérer et finissent par être encombrées. Vous avez plusieurs copies et vous ne pouvez pas vous souvenir de quelle copie pour quoi, puis essayez de savoir quand il est sécuritaire de les supprimer.

Tout cela devient encore plus précieux lorsque l'expérience implique des modifications coordonnées sur plusieurs fichiers. Et quand il s’agit d’un projet solo utilisant Git, cela devient encore plus simple.

Au lieu de me demander si je devrais l'utiliser sur un projet solo, je pense maintenant à quel dommage de ne pas l'avoir découvert plus tôt.