Jak uniknąć pracy w niewłaściwym oddziale?

27

Ostrożność zwykle wystarcza, aby zapobiec problemom, ale czasami muszę dwukrotnie sprawdzić gałąź, nad którą pracuję ( np. „Hmm ... jestem w devgałęzi, prawda?”), Sprawdzając losową ścieżkę kontroli źródła plik.

Szukając łatwiejszego sposobu, pomyślałem o odpowiedniej nazwie plików rozwiązania ( np. MySolution_Dev.sln ), Ale z różnymi nazwami plików w każdej gałęzi, nie mogę scalić plików rozwiązania.

Nie jest to wielka sprawa, ale czy są jakieś metody lub „małe sztuczki”, których używasz, aby szybko upewnić się, że jesteś we właściwej branży? Używam Visual Studio 2010 z TFS 2008.

henginy
źródło
2
To brzmi jak dobry kandydat do napisania rozszerzenia VS 2010, które pozwala na jakąś konfigurowalną wizualną wskazówkę wskazującą gałąź. Być może kolorowanie tła Eksploratora rozwiązań zgodnie z ustawieniami użytkownika (zrobiłbym zielony dla Deva, żółty dla QA i czerwony dla Prod).
Jesse C. Slicer,
Fajny pomysł, pomógłby nawet wskaźnik na pasku tytułu VS.
henginy
1
Powiedziałbym, że powinno to być dość skuteczne. Mam ustawiony monit bash, aby zawierał moją gałąź git i czy pliki źródłowe są czyste, czy też wymagają
zalogowania
Czy TFS nie mieć coś równoważną git statuslub hg status?
Używam interfejsu użytkownika VS do operacji TFS, więc tak naprawdę nie mam pojęcia.
henginy

Odpowiedzi:

16

Korzystam z tej http://visualstudiogallery.msdn.microsoft.com/f3f23845-5b1e-4811-882f-60b7181fa6d6

Aktualizuje twój tytuł na przykład:

Rozwój \ mój projekt

lub

Główny \ mój projekt

lub

Release \ myproject

Mam nadzieję, że to pomoże

ynnok
źródło
Wygląda na to, że to zrobię, spróbuję ...
henginy
Używam tego rozszerzenia właśnie do tego celu. W rzeczywistości miałem właśnie zamieścić link, kiedy zobaczyłem, że ynnok już to zrobił.
Bobson
1
Skończyło się na tym, jak widzę w tytule, na której gałęzi jestem. Naprawdę niesamowite!!!
Piotr Kula,
Tak, to naprawdę bardzo wygodne!
henginy
16

Nazwij działające katalogi inaczej. Oznacza to, że jeśli twój projekt nosi tytuł „MY_PROJECT”, utwórz inny katalog roboczy dla każdej gałęzi. Jeśli istnieje jedna gałąź o nazwie „dev”, to potrzebujesz katalogu dla trunk i katalogu dla dev, jak poniżej:

~/henginy/projects/MY_PROJECT-trunk
~/henginy/projects/MY_PROJECT-dev
Matthew Rodatus
źródło
Właściwie działające katalogi mają różne nazwy. Ale w już otwartym programie Visual Studio (na przykład po przerwie na kawę i powrocie na biurko) muszę sprawdzić ścieżkę do pliku, aby zobaczyć katalog. Sądzę więc, że to najprostszy sposób i nie ma przed tym ucieczki?
henginy
2
@henginy To dobre wyjaśnienie. Aby to ustalić w programie Visual Studio, zatrzymuję kursor nad kartą otwartego pliku. Wyświetli etykietkę pełnej ścieżki do systemu plików, z której mogę ustalić, czy katalog główny to „-dev” czy „-trunk”. Spróbuj i sprawdź, czy to działa dla Ciebie.
Matthew Rodatus
1
Tak, właśnie w ten sposób „sprawdzam ścieżkę kontroli źródła losowego pliku” i staram się znaleźć szybszy sposób :)
henginy
@henginy Oh, racja. Powiedziałeś to w OP. Nie znam lepszego sposobu na zejście z czubka głowy. Wygląda na to, że wcale nie poprawiłem twojej sytuacji. :-(
Matthew Rodatus
Powinienem to wyjaśnić lepiej w swoim pytaniu. Dziękuję za pomoc!
henginy
8

Nie pracuję w ogólnej gałęzi deweloperów lub pni.

ZAWSZE pracuję w gałęziach funkcji. Po zakończeniu funkcji wykonuję następujące kroki.

  1. Eksplorator Open Source Control.
  2. Scal z dev w bieżącą gałąź funkcji.
  3. Napraw wszelkie konflikty i upewnij się, że wszystko nadal działa.
  4. Sprawdź ponownie. Scal funkcję do gałęzi deweloperów.
  5. Otwarte rozwiązanie deweloperskie.
  6. Checkin dev branch.
  7. Zamknij rozwiązanie deweloperskie.
  8. Pozwól CI zbudować i wdrożyć.

Mam tylko gałąź deweloperów otwartą na kilka minut i od razu ją zamykam.

CaffGeek
źródło
7

Możesz utworzyć pusty plik w każdej gałęzi, np. THIS_IS_TRUNK.txt w pniu i THIS_IS_DEV.txt w DEV.

robstel
źródło
2
To może faktycznie działać ... Zwłaszcza z podkreśleniem przed nazwą pliku, aby przenieść go w eksploratorze rozwiązań.
henginy
6

Dużo pracy (D) VCS wykonuję z wiersza poleceń. Gorąco polecam mieć twój szybki wyświetlacz, gdzie jesteś. Na przykład mój monit w repozytorium Git wygląda (robię to również dla SVN):

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

A jeśli repozytorium jest obecnie brudne (niezatwierdzone zmiany):

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

Mam również tło ustawione na czerwono, jeśli jestem zalogowany do prod, takie rzeczy. Uważam, że proste powiadomienia wizualne są dla mnie bardzo skuteczne.

Wspomniałeś, że często widzisz to najczęściej po powrocie do komputera. Po wyjściu znajduję notatkę, w której mój punkt skupienia (gałąź, numer błędu, funkcja) przykleił się do klawiatury, aby być bardzo skutecznym, pozwalając mi szybko wrócić do pracy, zamiast odtwarzać to, co zrobiłem ostatnio .

mitchellhislop
źródło
4

Istnieje bezpłatne rozszerzenie Visual Studio o nazwie TFS Solution Info, które może w tym pomóc. Pokazuje bieżącą gałąź i obszar roboczy w małym oknie, które można zadokować / przypiąć w dowolnym miejscu.

Glenn Arndt
źródło
Wygląda świetnie, ale obsługuje VS2012
Piotr Kula,
3

Używam VSCommands rozszerzenie (z Visual Studio 2012, ale nie jest to wersja 2010) i wygodnie umieszcza nazwę oddziału w lewym górnym rogu ekranu, a także w Solution Explorer.

W żaden sposób nie związany z produktem, tylko zadowolony użytkownik.

R0MANARMY
źródło
1
Niestety wygląda to świetnie, ale trzeba zapłacić za wszystkie dodatkowe rzeczy, które mogą nie być potrzebne :(
Piotr Kula,
2

Unikam pracy w niewłaściwej gałęzi, robiąc prawie wszystko w jednej gałęzi (w pniu - zgodnie z tzw. Strategią rozgałęzienia „niestabilny pień” ).

Przypadki, w których jestem zmuszony do aktualizacji gałęzi, są dość rzadkie - są to poprawki błędów przedprodukcyjnych i postprodukcyjnych (kod kandydata na produkt jest izolowany w gałęziach). Ponieważ te poprawki powinny być również w bagażniku, zwykle szkicuję, testuję i weryfikuję je bezpośrednio w bagażniku, a następnie przesyłam do gałęzi prod. Przeniesienie z reguły wymaga prostej kopii od 1 do 5 plików do rozgałęzienia i kompilacji.

  • Mam również trochę szczęścia, że ​​w większości moich projektów kierownictwo wolało przekonać klientów do korzystania z nowszych wersji zamiast łatania starych - to sprowadza część postprodukcyjną aktualizacji w oddziałach do prawie nieistotnego minimum.
komar
źródło
Naprawdę miło jest nie musieć utrzymywać poprzednich wydań. W takim przypadku, jak sądzę, użyłbym gałęzi tylko do celów eksperymentalnych.
henginy
@henginy Nie mogę sobie przypomnieć przypadków, w których miałem luksus, że wcale nie musiałem utrzymywać poprzednich wersji. Jednak podejście kierownictwa może mieć tutaj duże znaczenie: w zależności od tego można np. Wdrożyć 1-2 poprawki / rok w starszych gałęziach lub zadzierać z tymi połówkami cały czas
komnata
1

Konkretna odpowiedź zależy od używanego oprogramowania do kontroli wersji, ale zwykle istnieje polecenie, które pozwala łatwo zobaczyć gałąź, nad którą pracujesz. Na przykład w przypadku Subversion użyj svn infopolecenia w katalogu, aby zobaczyć adres URL tej gałęzi. Jeśli bardziej interesuje Cię konkretny plik, możesz to również określić:

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

Z adresu URL widzę, że moja kopia pliku foo.c znajduje się w gałęzi caleb-dev.

Nie muszę tego robić zbyt często, ponieważ mój lokalny katalog ma taką samą nazwę jak oddział. Szybkie spojrzenie na mój wiersz polecenia zwykle wystarcza, aby potwierdzić, że jestem we właściwym katalogu i dlatego pracuję w odpowiedniej gałęzi.

Caleb
źródło
1

Wiele odpowiedzi tutaj, ale żadna, która nie dotyka prostego rozwiązania, które mamy tam, gdzie pracuję: dla każdej gałęzi utwórz nową maszynę wirtualną zawierającą środowisko deweloperskie i sprawdź z właściwej gałęzi. Musisz to zrobić i zrobić to dobrze raz, a następnie po prostu przełączasz maszyny wirtualne, aby przełączać gałęzie.

Mason Wheeler
źródło