Як уникнути роботи на неправильній гілці?

Будьте обережні, як правило, достатньо, щоб запобігти проблемам, але іноді мені потрібно двічі перевірити гілку, над якою я працюю ( наприклад, "хм ... я в devгілці, правда?"), Перевіривши шлях управління джерелом випадкового файл.

Шукаючи більш простий спосіб, я подумав відповідно назвати файли рішення ( наприклад MySolution_Dev.sln ), але з різними іменами файлів у кожній гілці я не можу об'єднати файли рішення.

Це не така вже й велика угода, але чи існують якісь методи або "дрібні хитрощі", які ви швидко використовуєте, щоб переконатися, що ви в правильній галузі? Я використовую Visual Studio 2010 з TFS 2008.

Я використовую цей http://visualstudiogallery.msdn.microsoft.com/f3f23845-5b1e-4811-882f-60b7181fa6d6

Оновлення назви, наприклад:

Розробка \ мійпроект

або

Головна \ мійпроект

або

Відпустіть \ мійпроект

Сподіваюся, це допомагає

По-різному називайте робочі каталоги. Тобто, якщо ваш проект має назву "MY_PROJECT", створіть інший робочий каталог для кожної гілки. Якщо є одна гілка з назвою "dev", то вам знадобиться каталог для магістралі та каталог для dev, наприклад, такий:

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

Я не працюю в загальній галузі розвитку або ствола.

Я ВЖЕ працюю в галузях функцій. Коли функція виконана, я виконую ці кроки.

1. Провідник з відкритим вихідним кодом.
2. Об’єднатись від розробника в поточну галузь функції.
3. Виправте будь-які конфлікти та переконайтесь, що все працює.
4. Зареєструйтесь ще раз. Об'єднати функцію у відділення розробки.
5. Відкрите рішення для розробників.
6. Відділення відділення Checkin
7. Закрити рішення розробника.
8. Нехай CI будує та розгортає.

У мене відкривається лише відділення розробника на кілька хвилин за один раз і відразу його закриваю.

Ви можете створити порожній файл у кожній гілці, наприклад THIS_IS_TRUNK.txt у стовбурі та THIS_IS_DEV.txt у DEV.

Я роблю багато своєї роботи (D) VCS з командного рядка. Я настійно рекомендую вам швидко відображати, де ви перебуваєте. Наприклад, моє підказка, коли в Git repo виглядає (я це роблю і для SVN):

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

А якщо РЕПО наразі забруднене (невідомі зміни):

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

У мене також фон встановлений на червоний, якщо увійшов у додаток, такі речі. Я вважаю прості візуальні сповіщення для мене надзвичайно ефективними.

Ви згадали, що найчастіше це бачите після повернення до свого комп’ютера. Я вважаю, що це повідомлення було помічено, оскільки мій поточний фокус (гілка, помилка #, функція) прилип до моєї клавіатури, коли я виїжджаю, щоб бути надзвичайно ефективним, що дозволяє мені швидко повертатися до роботи, а не відтворювати все, що я робив останнім часом .

Існує безкоштовне розширення Visual Studio під назвою Інформація про TFS Solution, яка може допомогти в цьому. Він показує вам поточну гілку та робочу область в маленькому вікні, яке ви можете докинути / підключити куди завгодно.

Я використовував розширення VSCommands (у Visual Studio 2012, але є версія 2010 року), і це зручно розміщувати назву гілки у верхньому лівому куті екрана, а також у провіднику рішень.

Ні в якому разі не пов'язаний з продуктом, просто щасливий користувач.

Я уникаю роботи в неправильній гілці, роблячи майже все в одній гілці (в магістралі - за так званою стратегією розгалуження "нестабільний стовбур" ).

Випадки, коли я змушений оновлювати гілки, є досить рідкісними - це виправлення до і після виправлення (код кандидата prod призначений у відділеннях). Оскільки ці виправлення мають бути і в магістралі, я зазвичай проектую, тестую і перевіряю їх там, де в магістралі, а потім портувати до відділення prod. Перенесення, як правило, включає просто просту копію від 1 до 5 файлів, щоб перевірити гілку та скласти чек.

• Я також кілька пощастило , що в більшості своїй вважали за краще управління проектами , щоб переконати клієнтів використовувати нові релізи , а не латати старі - це приносить пост-продакшн частина оновлень в філіях практично нікчемною мінімуму.

Конкретна відповідь залежить від програмного забезпечення для управління версіями, яке ви використовуєте, але зазвичай є команда, яка дозволяє легко бачити гілку, над якою ви працюєте. Наприклад, за допомогою Subversion використовуйте svn infoкоманду в каталозі, щоб побачити URL-адресу цієї гілки. Якщо вас більше цікавить конкретний файл, ви також можете вказати це:

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

З URL-адреси я бачу, що моя копія foo.c знаходиться у відділенні caleb-dev.

Мені це не потрібно робити дуже часто, оскільки мій локальний каталог має те саме ім'я, що і гілка. Швидкий огляд мого командного рядка, як правило, достатньо, щоб підтвердити, що я перебуваю в правильному каталозі, і тому працюю в правій гілці.

Тут вже знайдено багато відповідей, але жоден, що не стосується простого рішення, в якому я працюю: для кожної гілки створіть нове VM, що містить середовище розробників, і виберіть відповідну гілку. Вам потрібно зробити це лише один раз, і все виправте, і тоді ви просто перемкнете VM для перемикання гілок.