Come evitare di lavorare sul ramo sbagliato?

Fare attenzione di solito è abbastanza per prevenire problemi, ma a volte ho bisogno di ricontrollare il ramo su cui sto lavorando ( es. "Hmm ... sono nel devramo, giusto?") Controllando il percorso di controllo del codice sorgente di un casuale file.

Nel cercare un modo più semplice, ho pensato di nominare i file della soluzione di conseguenza ( ad es. MySolution_Dev.sln ) Ma con nomi di file diversi in ciascun ramo, non riesco a unire i file della soluzione.

Non è un grosso problema, ma ci sono metodi o "piccoli trucchi" che usi per assicurarti rapidamente di essere nel ramo giusto? Sto usando Visual Studio 2010 con TFS 2008.

Sto usando questo http://visualstudiogallery.msdn.microsoft.com/f3f23845-5b1e-4811-882f-60b7181fa6d6

Aggiorna il tuo titolo, ad esempio:

Sviluppo \ myproject

o

Main \ myproject

o

Rilascia \ myproject

Spero che sia d'aiuto

Denominare le directory di lavoro in modo diverso. Cioè, se il tuo progetto è intitolato "MY_PROJECT", crea una directory di lavoro diversa per ciascun ramo. Se esiste un ramo chiamato "dev", allora avresti bisogno di una directory per trunk e di una directory per dev, come questa:

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

Non lavoro in un ramo generico di sviluppo o tronco.

Lavoro SEMPRE nei rami delle caratteristiche. Al termine di una funzione, seguo questi passaggi.

1. Open Source Control Explorer.
2. Unisci dallo sviluppatore al ramo di funzionalità corrente.
3. Risolvi eventuali conflitti e assicurati che tutto funzioni ancora.
4. Effettua nuovamente il check-in. Unisci funzionalità nel ramo di sviluppo.
5. Apri la soluzione di sviluppo.
6. Checkin dev branch.
7. Chiudi la soluzione di sviluppo.
8. Consenti a CI di creare e distribuire.

Ho solo il ramo di sviluppo aperto per pochi minuti alla volta e lo chiudo subito.

È possibile creare un file vuoto in ciascun ramo, ad es. THIS_IS_TRUNK.txt nel trunk, e THIS_IS_DEV.txt in DEV.

Faccio molto del mio lavoro (D) VCS dalla riga di comando. Consiglio vivamente di avere il tuo prompt visualizzato dove ti trovi. Ad esempio, il mio prompt in un repository Git è simile (lo faccio anche per SVN):

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

E se il repository è attualmente sporco (modifiche non confermate):

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

Ho anche lo sfondo impostato su rosso se loggato in prod, cose del genere. Trovo che le semplici notifiche visive siano super efficaci per me.

Hai detto che lo vedi spesso dopo essere tornato sul tuo computer. Trovo un post-it note, con il mio focus attuale (branch, bug #, feature) incollato alla mia tastiera quando me ne vado, per essere super efficace nel permettermi di tornare al lavoro rapidamente, piuttosto che ricreare qualunque cosa fossi l'ultima volta .

C'è un'estensione gratuita di Visual Studio chiamata TFS Solution Info che può esserti utile. Ti mostra il ramo e l'area di lavoro correnti in una piccola finestra che puoi agganciare / bloccare ovunque tu voglia.

Ho usato l' estensione VSCommands (con Visual Studio 2012, ma esiste una versione 2010) e inserisce comodamente il nome del ramo nell'angolo in alto a sinistra dello schermo e in Esplora soluzioni.

Non affiliato al prodotto in alcun modo, solo un utente felice.

Evito di lavorare nel ramo sbagliato facendo quasi tutto in un ramo (nel tronco - per la cosiddetta strategia di ramificazione "tronco instabile" ).

I casi in cui sono costretto ad aggiornare i rami sono piuttosto rari: si tratta di correzioni di pre e post produzione (il codice del candidato è isolato nei rami). Dato che anche queste correzioni dovrebbero trovarsi nel trunk, di solito le bozze, le collaudo e le collaudo proprio lì nel trunk, quindi porto al ramo di prod. Il porting di regola prevede solo una copia semplice da 1 a 5 file per eseguire il branch e il build check.

• Sono anche un po 'fortunato che nella maggior parte dei miei progetti il ​​management abbia preferito convincere i clienti a utilizzare versioni più recenti invece di correggere quelle vecchie - questo porta la parte post-produzione degli aggiornamenti nelle filiali al minimo quasi trascurabile.

Una risposta specifica dipende dal software di controllo della versione che stai utilizzando, ma di solito c'è un comando che ti consente di vedere facilmente il ramo su cui stai lavorando. Ad esempio, con Subversion, utilizzare il svn infocomando in una directory per visualizzare l'URL per quel ramo. Se sei più interessato a un determinato file, puoi specificare anche quello:

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

Dall'URL, posso vedere che la mia copia di foo.c si trova nel ramo caleb-dev.

Non ho bisogno di farlo molto spesso perché la mia directory locale ha lo stesso nome del ramo. Una rapida occhiata al mio prompt della riga di comando è in genere sufficiente per confermare che sono nella directory giusta e quindi sto lavorando nel ramo giusto.

Molte risposte qui già, ma nessuna che tocca la semplice soluzione che abbiamo dove lavoro: per ogni ramo, creare una nuova macchina virtuale contenente un ambiente di sviluppo e verificare dal ramo appropriato. Devi solo farlo e farlo bene una volta, quindi devi semplicemente cambiare macchina virtuale per cambiare ramo.