Contrôle de version: Git et SVN

Version Control et une comparaison de Git et SVN. Le contrôle de version permet à plusieurs développeurs de travailler sur le même projet, mais qui est le mieux? Git ou SVN?

A+ A-

Le contrôle de version vous permet de garder une trace de toutes les versions de vos projets et des changements de code. Il maintient un répertoire de votre projet fichiers ainsi que tous les changements et les modifications apportées à ces fichiers. Ceci à son tour permet à toute personne travaillant avec le projet pour accéder aux changements, qui les fait et pourquoi. Il est essentiel que les développeurs ont accès à cette information.

Contrôle de version Git et SVN

Il existe deux grands référentiels de contrôle de version: Git et SVN, chaque logiciel libre étant distribué sous la GNU General Public License . SVN est court pour Apache Subversion alors Git est juste que. Il existe des différences entre les deux qui attirent leurs propres partisans, bien que beaucoup balancement vers Git en raison du contrôle qu'ils ont sur les dépôts qu'ils travaillent. Plus d'informations sur ce sujet sous peu.

Le besoin de contrôle de version

Au sein d'une équipe de développeurs chaque individu doit être en mesure d'accéder à la version actuelle d'un projet. Ils doivent également être en mesure de travailler sur cette version individuellement; le code est pas un livre de bibliothèque qui peut emprunter, changé et puis mettre à nouveau. Chaque membre de l'équipe doit avoir accès en cas de besoin, et ne pas attendre le code doit être retourné avant de pouvoir voir la dernière version.

Un problème majeur avec deux développeurs travaillant sur le même projet en même temps que chaque développeur subséquent enregistrer le projet et ainsi de remplacer toutes les modifications apportées précédemment sans trace d'eux. Le contrôle de version permet aux développeurs d'accéder à un projet et travailler sur elle tandis que d'autres font la même chose. Une fois qu'ils ont terminé leur travail, il sera envoyé dans le référentiel avec les changements fusionnés dans le contrôle de version.

Ce que cela signifie est qu'il ya une copie de chaque version disponible pour les développeurs. Si un changement ne fonctionne pas comme il se doit, vous retournez simplement à la version précédente et recommencer. Vous n'êtes pas obligé d'accéder à toutes vos modifications et retirez-les revenir à l'état précédent du développement. l'histoire de code est essentiel, et sans contrôle de version, il n'y aurait aucun.

Blame Feature

La fonction de blâme se réfère à un développeur, dites-vous, de savoir pourquoi un changement de code particulier a été fait. Utilisation du contrôle de version, vous pouvez établir l'auteur de ce changement et demander le raisonnement. Cela peut être pour des raisons pédagogiques, ou d'établir qui a besoin de recyclage!

Compte tenu de cette explication de contrôle de version, ce qui est mieux: Git ou SVN? Il existe d'autres, mais ce sont les deux référentiels les plus populaires. Voici comment chacun travaille:

SVN (Apache Subversion)

SVN est assez simple à utiliser. Si vous utilisez WordPress, c'est le plugin que vous utiliserez probablement. Votre référentiel se présente sous la forme d'un serveur central avec trois domaines fondamentaux: le tronc, les branches et les étiquettes.

Le coffre

Le tronc est l'endroit où vous devez garder votre code stable. Vous ne devez jamais envoyer un code unproved expérimentale ici, parce que c'est là où d'autres développeurs travaillant sur le même projet auront accès à des mises à jour réalisables. Les seuls changements à fusionner dans le tronc devrait être terminé le codage.

Branches

Lorsque vous travaillez sur les nouveaux développements, vous ne les ajoutez pas dans le tronc, comme expliqué ci-dessus, mais si le code branche out. Ce que vous faites est de stocker une copie du tronc comme il est quand vous commencez dans un dossier dans la zone «de branche». Vous pouvez ensuite travailler dessus à partir de là, et le fusionner dans le tronc que lorsque votre codage est terminée.

Ce que cela signifie est que vous pouvez poursuivre votre développement dans votre propre espace sans perturber tout le codage déjà complet. D'autres peuvent faire la même chose, en gardant le tronc intact jusqu'à des changements permanents ont été prouvés.

Mots clés

Comme le terme l'indique, vous utilisez ce pour marquer votre code. Il est tout simplement une copie de votre code actuel placé dans un dossier d'étiquette que vous pouvez utiliser pour revenir à votre projet comme il était quand vous avez marqué lui. Vous n'utilisez une balise pour travailler o - il est tout simplement un signet de l'endroit où vous étiez à ce moment précis dans le cas où vous devez revenir en arrière.

Les balises sont généralement utilisés lorsque le code est prêt à être déployé. Une fois qu'il a été rempli et a fusionné dans le tronc, testé, il sera testé - alors vous marquer le tronc. Juste avant la libération. Ensuite, vous relâchez le développement à votre serveur live. Si la sortie ne fonctionne pas comme prévu, vous pouvez alors marquer cette étiquette comme cassé et revenir à votre balise précédente pour résoudre le problème.

Comment GIT Works

La principale différence entre Git et SVN est que le premier a un certain nombre de dépôts, par rapport à celle de SVN. Avec Git, il y a un dépôt central, mais il y a aussi des dépôts individuels pour chaque développeur.

Qu'est-ce que cela permet, est pour les développeurs de travailler dans leur référentiel si la centrale échoue. Le problème avec SVN est que dans le cas de défaillance référentiel, personne ne peut commettre un code jusqu'à ce qu'il ait été réparé. Pas aussi avec Git. Il n'y a pas de hold-up, et tout le monde peut poursuivre leur travail jusqu'à ce que le dépositaire central est de retour à la normale - puis ils peuvent déployer leur code en elle.

Git Référentiels individuels

référentiels individuels sont rapides et permettent aux développeurs de travailler par eux-mêmes jusqu'à ce qu'ils soient prêts à déployer leur code.

  1. D'abord, vous cloner le référentiel maître, la création d'un référentiel local sur votre propre ordinateur.
  2. Vous pouvez ensuite travailler.
  3. Si le code se révèle fonctionner très bien dans le clone, vous pouvez ensuite pousser les modifications dans le référentiel maître. Si non, vous ne l'avez pas nui au maître.

Dans l'étape 1, vous pouvez travailler fondamentalement comme vous le feriez avec SVN: création de branches et les étiquettes en utilisant le maître cloné que le tronc. Les développeurs préfèrent Git parce qu'ils ont chacun leur propre référentiel de travailler avec, et ne pas avoir besoin de commettre un code jusqu'à ce qu'ils aient testé entièrement dans leur clone.

Un autre avantage de Git que beaucoup aiment est qu'ils ont pas besoin d'être connecté en ligne. Ils peuvent stocker le référentiel maître de clone sur leur ordinateur et de travailler à partir de là. Ils peuvent donc travailler sur des projets sans la nécessité de rechercher une connexion ou hotspot sans fil.

VOIR AUSSI: Comment utiliser Git sur ​​Windows? .

Référentiels publiques et privées

Git vous permet d'avoir des référentiels locaux publics et privés. D'autres développeurs peuvent tirer des changements de vos dépôts locaux; d'où la nécessité d'un dépôt privé pour empêcher que cela se produise. Vous pouvez également appuyer des changements à partir de votre dépôt public via SSH. Il est en grande partie en raison de la capacité de Git pour vous permettre d'utiliser des référentiels clonées et locales que de nombreux développeurs préfèrent à SVN.

Bifurquer Repo: Quand l'utiliser

"Repo Forker" est utilisé lorsque vous souhaitez ajouter une contribution au projet de quelqu'un d'autre, ou d'utiliser leur projet comme un début pour votre propre. Lorsque vous fourchette, vous créez essentiellement un clone du dépôt ainsi que son histoire, à laquelle vous pouvez vous engager votre propre travail.

Si vous utilisez le modèle de fourche et de traction du développement open source, il est possible pour vous de commencer à apporter des modifications sans demander la permission des propriétaires du projet. Si vous voulez contribuer à votre travail en arrière, vous pouvez envoyer une «demande pull» de la pension fourchue à la pension d'origine.

Pour créer une fourche, d'abord localiser le référentiel pour être fourchue. Pour ce faire, vous pouvez utiliser la fonction «recherche» sur la barre de menu Bitbucket. Accédez au référentiel, puis cliquez sur le bouton «Fork». Vous verrez alors les options Fork que vous devez définir. Ceux-ci comprennent des options telles que le propriétaire, Description, autorisations, etc.

Une fois que vous avez terminé ces, cliquez sur Repository Fork et vous pouvez continuer à travailler sur la fourche. Une fois que vous avez fait vos commits nécessaires, vous pouvez les repousser dans le projet fourchue dans le même comme vous le feriez avec un dépôt régulier. Vous pouvez également tirer des changements en amont dans le référentiel d'origine en utilisant le code suivant:

git fetch upstream
git merge upstream/master

Cela tire les modifications apportées à l'origine après avoir cloné dans votre clone, et vous pouvez ensuite continuer à travailler sur la dernière version du référentiel.

Vous devez faire votre propre décision sur laquelle référentiel de contrôle de version vous convient le mieux. Dans certains cas, sur-complication de contrôle de version peut être source de confusion, mais il est important que vous êtes au courant de ce qui est disponible pour vous. Quel référentiel de contrôle de version que vous utilisez, celui qui vous sentez mieux, partager vos pensées sous forme de commentaires ci-dessous.