Comment « -référentiel local » concept différent de « branches » de développement du git?

Question

Dans un travail précédent, j'ai trouvé plus facile à gérer et à maintenir une branche pré-version stable (ou principale, selon la configuration) en ayant chaque travail de développeur sur son / sa propre branche. Nous avons seulement eu une seule instance de production, donc pas besoin de prendre en charge plusieurs versions des mêmes applications.

Cette branche « libération » est nommé de cette façon parce qu'il y avait une autre branche (principale) où nous ferions nos communiqués de mise en scène et de production de. Les branches ont été installés de telle sorte que le code seulement de la branche préversion pourrait être fusionné dans la branche de sortie. Ces fusions ont été nos postes de contrôle de l'examen du code. Le CI builds ont été faites à partir de cette branche préversion ainsi et il était à chaque développeur de fusion à partir de « pré-libération » à leur propre branche aux questions de fusionnement complexes migitage lorsque le développement pour que le corps du travail a été achevé.

S'il y avait un besoin pour les développeurs de jumeler et travailler ensemble d'une une fonctionnalité donnée, rien que leurs propres branches les autorisations les ont empêchés de travailler avec les autres. Cela a bien fonctionné pour gérer les équipes distribuées où les individus au sein de chaque équipe travaillaient sur les caractéristiques distinctes / multiples.

Avec l'aide de fréquentes (1-2 fois par semaine) réunions de mise à jour de l'état de 30 minutes, nous en tant qu'équipe, déciderait irait dans l'assurance qualité et ce ne serait pas pour cette version particulière d'assurance qualité.

Ce système a fonctionné, mais je trouve beaucoup de ressentiment pour les branches de développement lors de la recherche sur ce sujet. Il semble y avoir beaucoup d'enthousiasme sur la fonction de dépôt local de git. Pourtant, il semble que ce sont juste des façons différentes d'aborder les mêmes problèmes. Ne pas tenir compte des questions inter-réseaux qui adresse les dépôts locaux, tels que l'enregistrement de la latence et tel.

Answer 1

Il existe trois différences principales:

1. signifie dépôt local juste que: Il est local à votre système, et si jamais vous vous échouées sur une île déserte sans connexion Internet, vous serez toujours en mesure de valider vos modifications. L'une des meilleures choses à propos Git est que vous ne devez pas être connecté à votre dépôt pour être en mesure de tirer profit du système de contrôle de version. Les développeurs travaillent parfois à distance sans être en mesure d'accéder au référentiel principal et qui peuvent généralement être salissant quand vous avez un système comme Subversion , Perforce , ou un autre type de contrôle de version du référentiel centralisé système. Avec Git et BitKeeper , vous pouvez facilement travailler hors ligne.

2. Dans branche développeur la situation, vous êtes normalement ramification de la intégration branche à votre développeur branche et réinsèrent à la intégration branche. Dans Git, vous ne fusionnez pas, mais envoyer des patches et vous pouvez envoyer vos modifications non seulement au référentiel maître , mais à d'autres développeurs sans avoir d'abord envoyer votre patch au dépôt maître . Cela permet aux développeurs de travailler ensemble sans toucher le référentiel maître .

3. Dans développeur / intégration configuration de branche, le branche développeur est dans le dépôt ce qui signifie que d'autres peuvent le voir. Dans Git, les modifications du développeur ne sont pas disponibles jusqu'à ce que le développeur offre leurs modifications.

Answer 2

Un DVCS comme Git ou Mercurial présente un workflow de publication (push / pull) qui est orthogonal à ramification .

Cela signifie que:

• même si tous les développeurs travaillent sur la même branche, ils peuvent le faire « en privé » sur leur propre repo: tant qu'ils ne publient pas, ils travaillent (c.-à pousser à une prise en pension en amont), que commune branche est en fait leur propre. Ils peuvent tirer (chercher + fusion) régulièrement afin de ne pas trop diverger du travail des autres sur le même sujet, mais ils pousseront lorsque vous êtes prêt.

• un développeur pourrait même jamais pousser son / son travail, mais un intégrateur peut chercher, à partir d'un référentiel « d'intégration » en amont, comme beaucoup branche (avec le même nom) à partir que les prises en pension de de nombreux développeurs que les besoins de l'intégrateur à: chaque branche sera magasin dans la prise en pension d'intégration dans son propre espace de noms (dev1/branch, dev2/branch, dev3/branch, ...)
  A partir de là, l'intégrateur peut regarder les commits la branche de chaque développeur est l'introduction, et décident de fusionner ou non ces changements dans la prise en pension d'intégration.
  Note: Ceci est légèrement différent dans Mercurial, étant donné que la branche du nom ont des noms dans un espace de noms global (Voir Jakub Narebski de l ' réponse sur " Git et Mercurial - Comparer et Contraste", regardant le "opinion personnelle: Je pense personnellement que "branches nommées" ..." partie)

Alors un connard « repo locale » transformer une branche dans la branche d'un développeur (qui ne l'empêche pas un développeur de faire son / sa propre branche privée au-dessus de ceux provenant d'un repo commun).
Ces branches sont disponibles pour la publication active (poussée par le développeur) ou publication passive (pull ou chercher à partir d'une prise en pension en amont, sans intervention directe dudit développeur)

---

Qu'est-ce que David W 's réponse (upvoted) fait plus nette est la différence entre:

• travail d'une branche dans une nouvelle branche (qui pourrait être lié à un développeur, même si je préfère les branches liées à une tâche ou un ensemble de tâches, afin d'isoler un effort de développement: voir « Quand faut-branche ")
• travail d'une branche cloné à partir d'une prise en pension dans votre propre repo: vous pouvez travailler sur le même branche, sauf qu'il est un clone (copie) de ladite branche à partir d'une prise en pension en amont
  . Si la prise en pension de développeur est pas accessible par un intégrateur, alors oui, comme David dit: « Dans Git, les modifications du développeur ne sont pas disponibles jusqu'à ce que le développeur offre ses changements. ».
  Si le repo du développeur est accessible (même par un simple « protocole local » comme un réseau part), alors peut être tiré de la prise en pension en aval à une prise en pension en amont d'intégration)
change du développeur

Voir aussi « Décrivez votre flux de travail en utilisant la version commande (VCS ou DVCS) » pour une autre façon de comparer la manière centralisée à l'aide de VCS branches par rapport à la manière décentralisée VCS à l'aide de dépôts.

Answer 3

Si cela a fonctionné pour vous, grand. Je pense que vous trouveriez cela fonctionnerait encore mieux avec un DVCS, car ils peuvent soutenir tout ce que vous faites maintenant et plus.

L'un des avantages d'un dépôt local sur une branche de développement est que vous pouvez avoir autant de branches que vous voulez localement. Vous pouvez faire tourner une branche rapide à quelque chose de test que vous êtes curieux de savoir. Vous pouvez faire tourner une branche à la migration de test à la dernière version de cette bibliothèque que vous aimez. Tout cela sans avoir besoin de « polluer » le serveur centralisé avec des choses qui voient peut-être ne devrait jamais la lumière du jour.