Comment évitez-vous de travailler sur la mauvaise branche?

27

Être prudent est généralement suffisant pour éviter les problèmes, mais parfois je dois vérifier la branche sur laquelle je travaille ( par exemple "hmm ... je suis dans la devbranche, n'est-ce pas?") En vérifiant le chemin de contrôle de la source d'un aléatoire fichier.

En cherchant un moyen plus simple, j'ai pensé à nommer les fichiers de solution en conséquence ( par exemple MySolution_Dev.sln ) mais avec des noms de fichiers différents dans chaque branche, je ne peux pas fusionner les fichiers de solution.

Ce n'est pas si grave, mais y a-t-il des méthodes ou des «petits trucs» que vous utilisez pour vous assurer rapidement que vous êtes dans la bonne branche? J'utilise Visual Studio 2010 avec TFS 2008.

— henginy
source

2

Cela ressemble à un bon candidat pour une extension VS 2010 à écrire qui permet une sorte de repère visuel configurable pour indiquer la branche. Peut-être coloriser l'arrière-plan de l'Explorateur de solutions selon les paramètres utilisateur (je ferais vert pour Dev, jaune pour QA et rouge pour Prod).

— Jesse C. Slicer

Bonne idée, même un indicateur sur la barre de titre VS aiderait.

— henginy

1

Je dirais que cela devrait être assez efficace. J'ai mon invite bash définie pour inclure ma branche git et si les fichiers source sont propres ou s'ils ont besoin d'un

— enregistrement

TFS n'a-t-il pas quelque chose d'équivalent à git statusou hg status?

J'utilise l'interface utilisateur VS pour les opérations TFS, donc je n'ai pas vraiment d'idée.

— henginy

16

J'utilise ce http://visualstudiogallery.msdn.microsoft.com/f3f23845-5b1e-4811-882f-60b7181fa6d6

Met à jour votre titre pour par exemple:

Développement \ monprojet

ou

Principal \ monprojet

ou

Release \ myproject

J'espère que ça aide

— ynnok
source

Cela semble le faire, je vais l'essayer ..

— henginy

J'utilise cette extension exactement à cette fin. En fait, j'étais sur le point de publier le lien, quand j'ai vu que ynnok l'avait déjà fait.

— Bobson

1

J'ai fini par utiliser celui-ci comme je peux le voir dans le titre sur quelle branche je suis. Vraiment génial!!!

— Piotr Kula

Oui, c'est en effet très pratique!

— henginy

16

Nommez les répertoires de travail différemment. Autrement dit, si votre projet est intitulé "MON_PROJET", créez un répertoire de travail différent pour chaque branche. S'il y a une branche nommée "dev", alors vous auriez besoin d'un répertoire pour trunk et d'un répertoire pour dev, comme ceci:

~/henginy/projects/MY_PROJECT-trunk
~/henginy/projects/MY_PROJECT-dev

— Matthew Rodatus
source

Les répertoires qui fonctionnent réellement sont nommés différemment. Mais avec un Visual Studio déjà ouvert, (par exemple après avoir pris une pause-café et revenir à mon bureau), je dois vérifier le chemin d'un fichier pour voir le répertoire. Donc je suppose que c'est le moyen le plus simple et aucune échappatoire à cela?

— henginy

2

@henginy C'est une bonne clarification. Pour déterminer cela dans Visual Studio, je passe la souris sur l'onglet d'un fichier ouvert. Il affichera une info-bulle du chemin complet du système de fichiers, à partir de laquelle je peux déterminer si la racine est "-dev" ou "-trunk". Essayez cela et voyez si cela fonctionne pour vous.

— Matthew Rodatus

1

Oui, c'est exactement comme ça que je "vérifie le chemin de contrôle de la source d'un fichier aléatoire", et j'essaie de trouver un moyen plus rapide :)

— henginy

@henginy Oh, c'est vrai. Vous l'avez dit dans OP. Je ne connais pas de meilleur moyen de sortir du haut de ma tête. On dirait que je n'ai pas amélioré votre situation du tout. :-(

— Matthew Rodatus

J'aurais dû mieux clarifier cela dans ma question. Merci de votre aide!

— henginy

8

Je ne travaille pas dans une branche générique de développement ou de tronc.

Je travaille TOUJOURS dans les branches de fonctionnalités. Quand une fonctionnalité est terminée, je suive ces étapes.

Explorateur de contrôle Open Source.
Fusionner de dev dans la branche de fonctionnalité actuelle.
Corrigez tous les conflits et assurez-vous que tout fonctionne toujours.
Enregistrez-vous à nouveau. Fusionner la fonctionnalité dans la branche dev.
Ouvrez la solution de développement.
Consigner la branche de développement.
Fermez la solution de développement.
Laissez CI construire et déployer.

Je n'ai que la branche de développement ouverte pendant quelques minutes à la fois et la ferme immédiatement.

— CaffGeek
source

7

Vous pouvez créer un fichier vide dans chaque branche, par exemple THIS_IS_TRUNK.txt dans le tronc et THIS_IS_DEV.txt dans DEV.

— robstel
source

2

Cela pourrait réellement fonctionner ... Surtout avec un trait de soulignement devant le nom du fichier pour le déplacer vers le haut dans l'explorateur de solutions.

— henginy

6

Je fais beaucoup de mon travail (D) VCS à partir de la ligne de commande. Je recommande fortement d'avoir votre affichage rapide où vous en êtes. Par exemple, mon invite quand dans un dépôt Git ressemble (je le fais aussi pour SVN):

[BranchName]RepoTop/path/to/current/wd >>

Et si le dépôt est actuellement sale (modifications non validées):

[BranchName!!]RepoTop/path/to/current/wd >>

J'ai également l'arrière-plan défini sur rouge si je suis connecté à prod, des choses comme ça. Je trouve que les notifications visuelles simples sont super efficaces pour moi.

Vous avez mentionné que vous le voyez souvent le plus après être revenu sur votre ordinateur. Je trouve un post it note, avec mon focus actuel (branche, bug #, fonctionnalité) collé à mon clavier lorsque je pars, pour être super efficace en me permettant de retourner au travail rapidement, plutôt que de recréer ce que j'ai fait en dernier .

— mitchellhislop
source

4

Il existe une extension Visual Studio gratuite appelée TFS Solution Info qui peut vous aider. Il vous montre la branche et l'espace de travail actuels dans une petite fenêtre que vous pouvez ancrer / épingler où vous le souhaitez.

— Glenn Arndt
source

Regardez génial mais prend en charge VS2012

— Piotr Kula

3

J'ai utilisé l' extension VSCommands (avec Visual Studio 2012, mais il existe une version 2010) et elle place facilement le nom de la branche dans le coin supérieur gauche de l'écran ainsi que dans l'explorateur de solutions.

Pas affilié au produit en aucune façon, juste un utilisateur heureux.

— R0MANARMY
source

1

Cela a l'air vraiment mal, malheureusement, vous avez dû payer pour toutes les choses supplémentaires qui pourraient ne pas être nécessaires :(

— Piotr Kula

2

J'évite de travailler dans la mauvaise branche en faisant presque tout dans une branche (dans le tronc - selon la stratégie de ramification dite "tronc instable" ).

Les cas où je suis obligé de mettre à jour des branches sont assez rares - ce sont des corrections de bugs de pré et post-production (le code candidat prod est isolé dans les branches). Étant donné que ces correctifs devraient également être dans le coffre, je les rédige, les teste et les vérifie généralement dans le coffre, puis je les transfère vers la branche prod. Le portage implique en règle générale une simple copie de 1 à 5 fichiers à créer et à vérifier.

Je suis également un peu chanceux que dans la plupart de mes projets, la direction ait préféré convaincre les clients d'utiliser des versions plus récentes au lieu de patcher les anciennes - cela réduit la partie post-production des mises à jour dans les succursales à un minimum presque négligeable.

— moucheron
source

C'est en effet agréable de ne pas avoir à maintenir les versions précédentes. Dans ce cas, je n'utiliserais qu'une branche à des fins expérimentales, je suppose.

— henginy

@henginy Je ne me souviens pas des cas où j'avais le luxe de ne plus avoir à maintenir les versions précédentes. Cependant, l'attitude de la direction peut faire une grande différence ici: en fonction de cela, on peut par exemple implémenter 1-2 correctifs / an dans les anciennes branches ou jouer avec ces la moitié du temps

— moucher

1

Une réponse spécifique dépend du logiciel de contrôle de version que vous utilisez, mais il existe généralement une commande qui vous permet de voir facilement la branche sur laquelle vous travaillez. Par exemple, avec Subversion, utilisez la svn infocommande dans un répertoire pour voir l'URL de cette branche. Si vous êtes plus intéressé par un fichier particulier, vous pouvez également le spécifier:

caleb-dev$ svn info foo.c 
Path: foo.c
Name: foo.c
URL: https://svn.mycompany.com/repo/sample/branches/caleb-dev/foo.c
Repository Root: https://svn.mycompany.com/repo/sample
Repository UUID: d62f7aef-3ad2-6098-12a-c16647d854ab
Revision: 1042
Node Kind: file
Schedule: normal
Last Changed Author: caleb
Last Changed Rev: 1031
Last Changed Date: 2011-06-07 15:28:27 -0400 (Tue, 07 Jun 2011)
Text Last Updated: 2011-06-08 03:08:12 -0400 (Wed, 08 Jun 2011)
Checksum: 123456789098765432123456789098

Depuis l'URL, je peux voir que ma copie de foo.c est dans la branche caleb-dev.

Je n'ai pas besoin de le faire très souvent car mon répertoire local a le même nom que la branche. Un rapide coup d'œil à ma ligne de commande est généralement suffisant pour confirmer que je suis dans le bon répertoire, et donc que je travaille dans la bonne branche.

— Caleb
source

1

Beaucoup de réponses ici déjà, mais aucune qui ne touche à la solution simple que nous avons là où je travaille: pour chaque branche, créez une nouvelle machine virtuelle contenant un environnement de développement et vérifiez à partir de la branche appropriée. Vous n'avez qu'à le faire et à bien faire les choses une fois, puis vous changez simplement de machine virtuelle pour changer de branche.

— Mason Wheeler
source