La théorie (et la terminologie) derrière le contrôle de code source

Question

J'ai essayé d'utiliser le contrôle de code source pour quelques projets, mais je ne le comprends toujours pas vraiment.Pour ces projets, nous avons utilisé TortoiseSVN et n'avons eu qu'une seule ligne de révisions.(Pas de ligne réseau, de branche ou quoi que ce soit de tout cela.) S'il existe une méthode recommandée pour configurer des systèmes de contrôle de source, quelles sont-elles ?Quels sont les raisons et les avantages d’une telle configuration ?Quelles sont les différences sous-jacentes entre le fonctionnement d’un système de contrôle de source centralisé et distribué ?

Answer 1

Je recommande de consulter ce qui suit d'Eric Sink :

http://www.ericsink.com/scm/source_control.html

La mise en place d'une sorte de système de contrôle des révisions est probablement l'outil le plus important dont dispose un programmeur pour examiner les modifications du code et comprendre qui a fait quoi à qui.Même pour les projets d'une seule personne, il est inestimable de pouvoir comparer le code actuel avec la version de travail connue précédente pour comprendre ce qui a pu mal se passer en raison d'un changement.

Answer 2

Considérez le contrôle de source comme un bouton géant « Annuler » pour votre code source.Chaque fois que vous vous enregistrez, vous ajoutez un point auquel vous pouvez revenir en arrière.Même si vous n'utilisez pas de branchement/fusion, cette fonctionnalité à elle seule peut être très utile.

De plus, en disposant d'une version « faisant autorité » du contrôle de code source, il devient beaucoup plus facile de le sauvegarder.

Centralisé vs.distribué...la différence est en réalité que dans une version distribuée, il n'y a pas nécessairement une version « faisant autorité » du contrôle de code source, bien qu'en pratique, les utilisateurs disposent toujours de l'arborescence principale.

Le grand avantage du contrôle de source distribué est double :

1. Lorsque vous utilisez le contrôle de code source distribué, vous disposez de l’intégralité de l’arborescence des sources sur votre ordinateur local.Vous pouvez valider, créer des branches et travailler à peu près comme si vous étiez tout seul, puis lorsque vous êtes prêt à appliquer vos modifications, vous pouvez les promouvoir depuis votre machine vers la copie principale.Si vous travaillez beaucoup « hors ligne », cela peut être un énorme avantage.

2. Vous n'avez besoin de demander la permission à personne pour devenir distributeur du contrôle de code source.Si la personne A exécute le projet, mais que les personnes B et C souhaitent apporter des modifications et partager ces modifications entre elles, cela devient beaucoup plus facile avec le contrôle de code source distribué.

Answer 3

Voici deux articles très utiles pour comprendre les bases.En plus d'être informative, la société Sink vend un excellent produit de contrôle de code source appelé Vault, gratuit pour les utilisateurs uniques (je ne suis en aucun cas affilié à cette société).

http://www.ericsink.com/scm/source_control.html

http://betterexplained.com/articles/a-visual-guide-to-version-control/

Informations sur le coffre-fort sur www.vault.com.

Answer 4

Même si vous ne créez pas de branche, vous trouverez peut-être utile d'utiliser des balises pour marquer les versions.

Imaginez que vous avez déployé hier une nouvelle version de votre logiciel et que vous avez commencé à apporter des modifications majeures pour la prochaine version.Un utilisateur vous appelle pour signaler un bug sérieux dans la version d'hier.Vous ne pouvez pas simplement le réparer et copier les modifications de votre tronc de développement, car les modifications que vous venez de rendre le tout instable.

Si vous aviez marqué la version, vous pouvez en consulter une copie de travail et l'utiliser pour corriger le bogue.

Ensuite, vous pouvez choisir de créer une branche au niveau de la balise et d'y intégrer le correctif de bogue.De cette façon, vous pouvez corriger davantage de bogues sur cette version tout en continuant à mettre à niveau le tronc.Vous pouvez également fusionner ces correctifs dans le coffre afin qu'ils soient présents dans la prochaine version.

Answer 5

La norme courante pour configurer Subversion est d'avoir trois dossiers à la racine de votre dépôt :tronc, branches et étiquettes.Le dossier Trunk contient votre ligne de développement « principale » actuelle.Pour de nombreux magasins et situations, c'est tout ce qu'ils utilisent...juste un seul référentiel de code fonctionnel.

Le dossier tags va encore plus loin et vous permet de « vérifier » votre code à certains moments.Par exemple, lorsque vous publiez une nouvelle version ou parfois même lorsque vous faire une nouvelle version, vous "marquez" une copie dans ce dossier.Cela vous permet simplement de savoir exactement à quoi ressemblait votre code à ce moment-là.

Le dossier branches contient différents types de branches dont vous pourriez avoir besoin dans des situations particulières.Parfois, une branche est un endroit où travailler sur des fonctionnalités expérimentales ou des fonctionnalités qui peuvent prendre beaucoup de temps à devenir stables (vous ne souhaitez donc pas les introduire dans votre ligne principale pour l'instant).D'autres fois, une branche peut représenter la copie de « production » de votre code qui peut être modifiée et déployée indépendamment de votre ligne de code principale qui contient des modifications destinées à une version future.

Quoi qu'il en soit, ce n'est qu'un aspect de la façon de configurer votre système, mais je pense qu'il est important de réfléchir à cette structure.