Je suis en train de développer un site Web en php dans localhost et au fur et à mesure que ses modules sont terminés, je le télécharge sur le cloud afin que mes amis puissent le tester en alpha.

Alors que je continue de développer, j'ai beaucoup de fichiers et je perds la trace du fichier que j'ai édité ou changé, etc.

Donc, ma question est: Existe-t-il un moyen / service / application facile à suivre pour suivre toutes les modifications / modifications / nouveaux fichiers et gérer les fichiers pendant que je développe le site Web. Dès que j'en ai fini avec un module, je veux le télécharger sur le cloud (j'utilise Amazon Cloud Service). Si quelque chose arrive aux nouveaux fichiers, je pourrais vouloir revenir à l'ancien fichier. Et peut-être, en un ou deux clics, j'arrive à voir les fichiers que j'ai édités ou modifiés depuis le dernier que j'ai téléchargé?

La gestion de la configuration logicielle , dont le contrôle de version fait partie, est un peu plus complexe que le suivi des modifications apportées aux fichiers, bien que vous puissiez certainement commencer par cela. Mais lisez les articles Wikipedia liés ci-dessus ainsi que le tutoriel de Joel Spolky sur Mercurial .

Pour commencer, choisissez l'un de Mercurial, GIT ou Bazaar, dans cet ordre, et installez-le avec des outils pour votre IDE et votre système d'exploitation (je préfère Mercurial avec HGE pour Eclipse).

1. Initialisez un référentiel à partir de votre répertoire de travail ( hg init avec Mercurial).
2. Décidez quels fichiers et répertoires vous souhaitez suivre et lesquels ne le sont pas. La règle générale n'est pas de suivre les fichiers générés par les compilateurs et autres outils.
3. Utilisez la commande pour ajouter les fichiers et les répertoires au référentiel ( hg add pour Mercurial).
4. Indiquez à l'outil les modèles des fichiers que vous ne souhaitez pas suivre (modifiez .hgignore pour Mercurial).
5. Effectuez un commit pour suivre les versions originales ( hg ci ).
6. Effectuez une validation après chaque jalon logique, même s'il est petit.
7. Ajoutez de nouveaux fichiers au fur et à mesure que vous les créez.
8. Répétez les deux derniers.
9. Sauvegardez votre répertoire de travail et le référentiel aussi souvent que possible.

Avec vos fichiers dans le référentiel, vous pouvez connaître les différences entre deux versions d'un fichier ou d'un répertoire ou le projet complet ( hg diff ), voir l'historique des modifications ( hg hist ) et annuler les modifications ( hg up -r ).

C'est une bonne idée de baliser (balise hg ) le référentiel avant de publier votre code afin qu'il y ait un moyen facile de revenir exactement à ce que vous avez publié pour des modifications ou des comparaisons.

Si vous souhaitez expérimenter avec une ligne de développement différente, faites-le dans une branche simple en clonant le référentiel principal ( clone hg ) et en ne repoussant pas tant que l'expérience n'est pas concluante. C'est aussi simple que d'avoir un répertoire de travail différent pour l'expérience.

Si l'expérience concerne une nouvelle version mise à niveau, clonez puis branchez (branche hg ) afin que vous puissiez garder toutes les copies des référentiels mises à jour sans qu'une expérience n'interfère avec l'autre.

Linus Torvalds (qui traite des dizaines de milliers de fichiers et des millions de lignes de code dans ses projets) a expliqué à Google pourquoi l'outil ne peut pas être CVS, SVN ou l'un des nombreux logiciels gratuits et commerciaux autour ; cela vaut vraiment la peine d'être regardé.

Je recommanderais vivement Git. Apprenez-en plus ici: https://lab.github.com/

Si vous n'aimez pas Git, il existe d'autres solutions de contrôle de version. Vous pouvez consulter SVN.

Est-ce juste toi ?, utilise un DVCS

Aussi contre-intuitif que cela puisse paraître, un système de contrôle de version distribué (mercurial, git, bazaar) est préférable de commencer qu'un système centralisé (svn, cvs). Pourquoi?, Vous l'installez sur votre machine et exécutez votre référentiel localement, et c'est tout. Sur un système centralisé tel que svn, vous devez configurer votre client et un serveur ... et ensuite, vous devez vous connecter à un serveur pour stocker vos modifications.

Avec un DVCS, c'est vous, le référentiel local, et si vous le souhaitez, vous pouvez utiliser un service comme bitbucket.org ou github.com.

À mon humble avis, mercurial est un DVCS plus convivial et tout aussi capable pour commencer.

Y en a-t-il d'autres?, Utilisez un DVCS!

Il y a de nombreux avantages à utiliser un DVCS pour travailler avec une équipe, le plus important contrairement à un système centralisé est qu'il n'y a pas de courses de commit et c'est parce que, techniquement, le référentiel de chaque individu est une branche, et lorsque vous partagez votre change ces branches sont fusionnées pour vous et vous ne le remarquez même pas, ce qui signifie qu'au lieu d'avoir un historique de version comme celui-ci, où vous avez des gens qui canalisent leur travail en ligne droite:

Vous finissez par avoir quelque chose comme ça, où tout le monde commet juste ad hoc:

Chacun s'inquiète simplement de son propre travail pendant le versionnage (c'est-à-dire qu'il ne fait pas la course pour valider) et ne se soucie pas d'une connexion à un serveur juste pour valider.

Bonne chance

Pour être bref, il existe de nombreuses alternatives, parmi lesquelles Subversion (SVN) et Git semblent les plus populaires (donc les plus faciles à trouver des solutions sur le web).

Ils diffèrent tous les deux. SVN est plus simple, mais Git ne vous oblige pas à avoir un serveur pour commencer - vous pouvez contrôler la version localement.

En supposant que vous avez Linux et que vous souhaitez commencer à utiliser Git:

1. Installer Git
2. Allez dans le répertoire et exécutez la commande 'git init'
3. Découvrez comment ajouter des fichiers, revoir les modifications, les valider ...
4. ... et pour faire des choses plus avancées (revoir les journaux, annuler les modifications, ignorer les fichiers, créer des branches, les fusionner, créer et utiliser des télécommandes, utiliser des sous-modules, utiliser le support SVN, etc.).

J'espère que cela vous aidera à commencer.

Comme Apalala le suggère, je recommande de commander hginit . Comme vous êtes nouveau dans le contrôle de version, vous pouvez ignorer la première page. Cela devrait vous donner une bonne introduction, ensuite vous pouvez poster sur SO si vous avez des questions spécifiques.

Je vais aller à l'encontre de l'opinion majoritaire et recommander Subversion. Subversion est facile à utiliser et fait tout ce dont les particuliers et les petites équipes ont besoin. C'est un produit mature, donc chaque IDE a un bon support. Oui, il n'a pas toutes les fonctionnalités de Git. (Je n'ai jamais utilisé Mercurial, donc je n'en parlerai pas.) Mais la plupart des développeurs n'ont pas réellement besoin de ces fonctionnalités supplémentaires.

Dépôts multiples? Je suis sûr qu'il y a des utilisations légitimes pour celles-ci, mais je ne les ai jamais rencontrées.

Pouvoir faire des commits locaux, sans accès au réseau? C'est bien d'avoir, si vous effectuez plusieurs modifications discrètes et que vous ne pouvez pas accéder au serveur de référentiel - mais honnêtement, à quelle fréquence cela se produit-il?

Git facilite la gestion des branchements et des fusions. Mais pour une équipe d'une personne, ce n'est pas si grave.

Pour quelque chose à l'échelle du noyau Linux - oui, utilisez Git. Pour le reste d'entre nous, Subversion est assez bon.

Je pense qu'un système de contrôle de version distribué fera bien l'affaire. Les choix couramment suggérés sont Git et Mercurial (Hg). Des outils graphiques peuvent être utiles, pour Mercurial, je recommande TortoiseHg .