Branchement flexible vs statique (GIT vs Clearcase / Accurev)

Question

Ma question est au sujet de la façon dont GIT gère branches: dès que l'on branche à partir d'un commit, cette branche ne pas toujours recevoir des modifications de la succursale parent, à moins que vous force avec une fusion.

Mais dans d'autres systèmes, tels que des Clearcase ou Accurev, vous pouvez spécifier la manière dont les branches se remplir avec une sorte de mécanisme d'héritage: je veux dire, avec Clearcase, à l'aide d'un config_spec, vous pouvez dire "tous les fichiers modifiés sur la branche /main/issue001 et puis continuer avec ceux qui sont sur le main ou spécifique à cette ligne de base".

Dans Accurev vous avez également un mécanisme similaire qui permettent de flux de recevoir des modifications de branches supérieures (cours d'eau, comment ils les appellent) sans fusion ou la création d'un nouveau commit sur la branche.

À ne pas manquer ce tout en utilisant GIT? Pouvez-vous énumérer les scénarios où cet héritage est un must?

Merci

Mise à jour , Veuillez lire VonC réponse ci-dessous pour regarder de ma question. Une fois que nous sommes d'accord "linéaire de stockage" et le DAG en fonction des Mec ont des capacités différentes, ma question est: qui sont les véritables scénarios de vie (en particulier pour les entreprises de plus de OSS) où linéaire peut faire des choses pas possible pour DAG? Sont-ils de la valeur?

Answer 1

Pour comprendre pourquoi Git n'offre pas une sorte de ce que vous faites référence à un "mécanisme d'héritage" (n'impliquant pas un commit), vous devez d'abord comprendre l'un des concepts de base de ces SCMs (Git vs ClearCase par exemple)

• ClearCase utilise une version linéaire de stockage: chaque version d'un élément (fichier ou répertoire) est liée directement linéaire de la relation avec la précédente version d'un même élément.

• Git utilise un DAG - Graphe Dirigé Acyclique: chaque "version" d'un fichier est en fait partie d'un ensemble global des changements dans un arbre qui est lui-même partie d'un commit. La version précédente de ce qui se trouve dans une précédente livraison, accessible via un unique graphe dirigé acyclique chemin.

Dans un système linéaire, une config spec pouvez spécifier plusieurs règles pour la réalisation de cet "héritage" vous voyez (pour un fichier, sélectionnez d'abord une certaine version, et si non présent, puis sélectionnez une autre version, et si non présent, puis sélectionnez un troisième, et ainsi de suite).

La direction est d'une fourchette dans un linéaire de l'histoire d'une version donnée d'une donnée, sélectionnez la règle (toutes les autres règles de sélection avant que l'on s'appliquent toujours, d'où le "héritage" de l'effet)

Dans un DAG, un commit représente tous les "héritage" que vous obtiendrez jamais; il n'y a pas de "montant cumulatif des" sélection de versions. Il y a seulement un chemin dans ce graphe pour sélectionner tous les fichiers que vous verrez sur ce point exact (commit).
Une branche est juste un nouveau chemin dans ce graphe.

Pour appliquer, dans Git, certaines autres versions, vous devez:

• fusionner dans votre branche certains autres commit (comme dans le git pull" mentionné par stsquad de réponse) ou
• rebase votre branche (comme Greg mentions)

Mais depuis Git est un DAG à base de SCM, il sera toujours le résultat dans un nouveau commit.

Ce que vous "perdre" avec Git est une sorte de "composition" (lorsque vous sélectionnez les différentes versions successives de sélectionner des règles), mais qui ne serait pas pratique dans un DVCS (comme dans "Distribué"): lorsque vous effectuez une branche Git, vous avez besoin de le faire avec un point de départ et un contenu clairement défini et facile à reproduire à d'autres dépôts.

Dans un but purement centrale VCS, vous pouvez définir votre espace de travail (dans ClearCase, votre "vue", soit instantané ou dynamique) avec toutes les règles que vous souhaitez.

---

inconnu-google ajoute dans le commentaire (et dans sa question ci-dessus):

Donc, une fois que nous voyons les deux modèles peuvent réaliser des choses différentes (linéaire vs DAG), ma question est: qui sont les véritables scénarios de vie (en particulier pour les entreprises de plus de OSS) où linéaire peut faire des choses pas possible pour DAG? Sont-ils la peine?

Quand il s'agit de "scénario de la vie réelle" en terme de règles de sélection, ce que vous pouvez faire dans un modèle linéaire est d'avoir plusieurs règles de sélection pour le même ensemble de fichiers.

Considérer cette "config spec" (c'est à dire "spécification de la configuration" pour les règles de sélection avec ClearCase):

element /aPath/... aLabel3 -mkbranch myNewBranch
element /aPath/... aLabel2 -mkbranch myNewBranch

Il sélectionne tous les fichiers portant la mention"aLabel2"(et de la branche à partir de là), à l'exception de ceux portant la mention"aLabel3' - et de la direction générale à partir de là (parce que la règle qui précède celui de mentionner 'aLabel2').

Est-il utile?

Pas de.

En fait, l'UCM, la saveur de ClearCase (le "Unifiée de Gestion de la Configuration" méthodologie inclus avec ClearCase produit, et représentant tous les "meilleures pratiques" déduite à partir de la base de ClearCase utilisation) ne le permet pas, pour des raisons de simplificity. Un ensemble de fichiers est appelé un "composant", et si vous voulez de la branche pour une étiquette donnée (appelée "ligne de base"), qui devrait être traduit comme ceci à la suite de config spec:

element /aPath/... .../myNewBranch
element /aPath/... aLabel3 -mkbranch myNewBranch
element /aPath/... /main/0 -mkbranch myNewBranch

Vous avez à choisir un point de départ (ici, 'aLabel3') et à partir de là. Si vous souhaitez également les fichiers à partir de 'aLabel2', vous pourrez faire une fusion de toutes les 'aLabel2' fichiers à celles dans "myNewBranch'.

C'est une "simplification" vous n'avez pas à faire avec un DAG, où chaque nœud du graphe représente un unique défini "point de départ" pour une branche, ce qui est de l'ensemble des fichiers concernés.

De fusion et rebase sont assez pour combiner le point de départ avec d'autres versions d'un ensemble de fichiers, afin d'atteindre les objectifs de "composition", tout en gardant cette histoire dans l'isolement dans une branche.

L'objectif général est de raisonner en "cohérent opérations de Contrôle de Version appliquée à un cohérentde composants". Une "cohérence" ensemble de fichiers est dans des conditions bien définies cohérente de l'état:

• si étiquetés, tous ses fichiers sont étiquetés
• si ramifiée, tous ses fichiers branche à partir de la même et unique point de départ

C'est facile à faire dans un groupe de disponibilité du système; il peut être plus difficile dans un système linéaire (en particulier avec la "Base de ClearCase" où la "config spec" peut être délicat), mais il est mis à exécution avec l'UCM méthodologie de la même linéaire en fonction de l'outil.

Au lieu de réaliser que la "composition" par le biais d'un "privé de sélection de la règle truc" (avec ClearCase, certains sélectionnez la règle de l'ordre), vous obtenez seulement avec les VCS opérations (rebase ou de fusion), qui laissent une trace apparente pour tout le monde à suivre (par opposition à une config spec privé pour un développeur, ou partagés entre certains, mais pas tous les développeurs). Encore une fois, qu'il applique un sens de la cohérence, par opposition à une "souplesse dynamique", que vous pouvez avoir un moment difficile de reproduire plus tard.

Qui vous permet de quitter le domaine de la VCS (Version Control System) et entrez dans le domaine du SCM (Logiciel de Gestion de la Configuration), qui s'occupe principalement de la "reproductibilité". Et que (SCM fonctions) peuvent être obtenus avec un linéaire ou d'un DAG à base de VCS.

Answer 2

Cela ressemble à ce que vous cherchez peut-être git rebase. La relocalisation d'une succursale sur le plan conceptuel se détache de l'original de son point de branchement et la rattache à un autre point. (En réalité, cela est mis en œuvre par l'application de chaque patch de la branche dans la séquence de la nouvelle succursale point, la création d'un nouveau lot de correctifs.) Dans votre exemple, vous pouvez rebase une branche à la pointe de courant de la haute direction, qui sont essentiellement des "héritent" de toutes les modifications apportées à l'autre branche.

Answer 3

Je ne suis pas tout à fait clair sur ce que votre demande, mais il semble que git est le suivi de la sémantique sont ce que vous voulez. Lorsque vous branche à partir de l'am origine vous pouvez faire quelque chose comme:

git -t -b my_branch origin/master

Et puis l'avenir "git pull"s auto fusion origin/master dans votre de travail de la branche. Vous pouvez ensuite utilisez "git cherry -v origin/master" pour voir quelle est la différence. Vous pouvez utilisez "git rebase" avant de la publier les changements de nettoyer l'histoire, mais vous ne devriez pas utiliser rebase une fois votre histoire est public (c'est à dire à d'autres personnes de la suite de cette branche).

Answer 4

Quant à l'héritage schéma utilisé par accurev: GIT les utilisateurs seront probablement "obtenir" l'ensemble de la chose lors de la regarder git-flow (voir aussi: http://github.com/nvie/gitflow et http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/)

Cette GIT branches plus ou moins (manuellement ou avec l'aide de git-flow de l'outil) ce accurev ne out-of-the-box automatiquement et avec grand support de l'IHM graphique.

Donc, il semble GIT peut faire ce accurev n'. Depuis je n'ai jamais réellement utilisé git/git-flow de la journée-à-jour, je ne peux pas vraiment dire comment il fonctionne, mais il a l'air prometteur. (Moins bon support de l'IHM graphique :-)

Answer 5

Je vais essayer de répondre à votre question. (Je dois dire ici que je n'ai pas utilisé GIT seulement lire à ce sujet, donc si quelque chose que je mentionne ci-dessous est faux, merci de me corriger)

"Pouvez-vous énumérer les scénarios où cet héritage est un must?"

Je ne vais pas dire que c'est un must, car vous pouvez résoudre un problème avec l'outil que vous avez, et peut-être une solution valide pour votre environnement. Je suppose que c'est plus une question de processus que l'outil lui-même. Assurez-vous que votre processus est cohérent et permet également de revenir en arrière dans le temps de reproduire n'importe quelle étape intermédiaire/état est l'objectif, et le plus est que l'outil permet d'exécuter vos processus et SCMP aussi indolore que possible

Le scénario que je peux voir, il est pratique d'avoir cet "héritage" de comportement et d'utiliser la puissance de la config spec, c'est quand vous voulez que votre ensemble de changements "isolé" mappé à une tâche (devtask, CR, SR, ou quel que soit définit le but et la portée de votre changement de set)

À l'aide de cette composition permet d'avoir votre branche de développement propre et de toujours utiliser la combinaison différente (à l'aide de la composition) du reste du code, et encore seulement ce qui est pertinent pour la tâche isolé dans une branche au cours de l' ensemble du cycle de vie de la tâche, jusqu'à ce que la phase d'intégration.

Être puriste avoir à s'engager/fusionner/rebase juste pour avoir un "définis point de départ" , je suppose qu'elle"polluer"votre direction et vous allez vous retrouver avec vos modifications + d'autres changements dans votre branche/de changement.

Quand/Où cet isolement est-il utile? Les points soufflet ne prennent de sens que sur le contexte de sociétés de la poursuite de la CMM et de certaines certifications ISO, et peut-être sans intérêt pour d'autres types d'entreprises ou de l'OSS

• Être vraiment pointilleux, vous pouvez compter précisément le nombre de lignes de code (ajout/modification/suppression) de l'ensemble de modifications correspondant à un seul développeur, plus tard utilisé comme une entrée pour le code et les estimations.

• Il peut être plus facile à réviser le code à différents stades, juste après avoir votre code dans une seule branche (pas collé avec d'autres changements)

Sur les gros projets avec plusieurs équipes et +de 500 développeurs travaillent activement en même temps sur la même base de code, (où le graphique des éléments individuels de la version des arbres ressemble à un enchevêtrement désordonné avec plusieurs loadlines, une pour chaque client, ou un pour chaque technologie ) grand config spécifications à l'aide de la composition de plusieurs degrés en profondeur du fait de cette quantité de personnes de travailler en toute transparence pour adapter le même produit/système (code de base) à des fins différentes. En utilisant cette configuration, spec, de façon dynamique a donné à chaque équipe ou de l'équipe secondaire, d'un point de vue différent de ce dont ils ont besoin et où ils ont besoin de la branche d', (en cascade sur plusieurs cas), sans la nécessité de la création d'intermédiaire intégration des branches, ou constamment la fusion et la relocalisation de tous les bits que vous avez besoin pour commencer. Code à partir de la même tâche et le but était de ramification de différentes étiquettes, mais fait sens. (Vous pouvez discuter ici de la "de référence connues" comme un principe de la SCM, mais de simples étiquettes envisagée dans un écrit SCM Plan a fait le travail) Il doit être possible de résoudre ce avec GIT (je suppose que non dynamique), mais je trouve vraiment difficile d'imaginer que sans cet "héritage" de comportement. Je suppose que le point mentionné par VonC "si ramifiée, tous ses fichiers branche de la même et unique point de départ" a été cassé ici, mais à côté, il a été bien documenté sur le SCMP, je me souviens il y avait de bonnes raisons de le faire de cette façon.

Oui la construction de ces config specs que j'ai mentionné ci-dessus n'était pas libre, au commencement, il y où 4-5 bien payé des gens derrière la SCM, mais ont ensuite été réduite par des scripts automatisés qui vous demandait ce que vous voulez sur les conditions d'étiquettes/branches/caractéristiques et écrire de la CS pour vous.

La reproductibilité ici a été réalisé en vient de sauver la Config Spec avec la tâche dans la devTask système, de sorte que chaque tâche en amont mappés à des exigences, et en aval mappé à une config spec, un ensemble de modifications (les fichiers de code, les documents de conception, de test de documents, etc)

Donc, jusqu'ici, une seule conclusion ici peut-être, mais seulement si votre projet est gros et assez compliqué (et que vous pouvez vous permettre SC Gestionnaires au long de la vie du projet:) ) ensuite, vous n'aurez commencer à penser si vous avez besoin de la "héritage" comportement ou vraiment outil polyvalent, sinon vous permettra d'accéder directement à un outil qui est gratuit et déjà prendre soin de la cohérence de vous SCM ... mais il pourrait y avoir d'autres facteurs sur le SCM outil qui pourrait vous faire tenir à l'un ou à l'autre ...lire la suite..

Certains de ces notes, qui pourrait être hors sujet, mais je suppose que dans certains cas comme le mien doivent être considérés.

Je dois ajouter ici que nous utilisons le "bon-ol CC" pas UCM. Tout à fait d'accord avec VonC sur une bonne méthodologie permet de "guide" de la flexibilité vers une approche plus cohérente de la configuration. La bonne chose est que le CC est assez flexible et vous pouvez trouver (non sans un certain effort) une bonne façon d'avoir un truc cohérent, alors que dans d'autres SCM vous pourriez avoir gratuitement. Mais par exemple ici (et à d'autres endroits que j'ai travaillé avec CC) pour les projets C/C++ on ne peut pas se permettre le prix de ne pas avoir le winkin fonctionnalité (réutilisation de la Tirer des objets), que la réduction de plusieurs X fois la compilation du temps. Il peut être soutenu que le fait d'avoir une meilleure conception , plus découplée de code, et l'optimisation des fichiers Makefile peut réduire le besoin de compiler l'ensemble de la chose, mais il ya des cas que vous avez besoin de compiler l'ensemble de la bête, plusieurs fois par jour, et le partage de la FAIRE enregistre des tas de temps/d'argent. Là où je suis maintenant, nous essayons de les utiliser, outil gratuit que nous le pouvons, et je pense qu'on va se débarrasser de CC si on peut trouver moins cher ou gratuit outil qui implémente l' winkin fonctionnalité.

Je vais en finir avec quelque chose que Paul mentionne , différents outils sont mieux que d'autres à des fins différentes , mais j'ajouterai que vous pouvez sortir de certaines limites de l'outil par le fait d'avoir un processus cohérent et sans scarification de la reproductibilité, les principaux points de la SCM À la fin, j'imagine que la réponse à il vaut la peine? dépend de votre "problème", le SDLC vous êtes en cours d'exécution, votre SCM des processus, et si il n'y a aucune fonctionnalité supplémentaire (comme winkin) qui pourrait être utile dans votre environnement.

mes 2 cents