Чи слід очікувати, що моя команда матиме більш ніж базове знання з нашою системою управління джерелами?

Моя компанія перейшла з Subversion на Git близько трьох місяців тому. Перед перемиканням ми мали попередні попередні повідомлення. Оскільки я ніколи раніше не використовував Git (або будь-який інший DVCS), я читав Pro Git і витратив трохи часу на те, щоб розкручувати власні сховища та грати, щоб, коли ми переключились, я міг би продовжувати працювати з мінімальними болями. Тепер я за замовчуванням я 'Git guy'.

За кількома винятками, більшість моєї команди досі не має уявлення про те, як працює Git. Наприклад, вони як і раніше вважають гілки повноцінними копіями вихідного коду і навіть заходять так далеко, щоб клонувати репо в декілька папок (по одній на гілку). Вони, як правило, дивляться на Гіта як на страшну чорну скриньку.

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

Чи варто сподіватися, що моя команда матиме хоч деяке розуміння того, як Git працює внутрішньо, і як ним користуватися поза основними операціями тяги / злиття / натискання? Або я просто щось роблю з нічого?

Професіоналізм, природно, диктує, що розробник ознайомлюється зі стандартними інструментами своєї команди, навіть якщо вони нові та незнайомі (або навіть небажані).

Однак кілька речей у твоєму посту дають мені паузу.

Перед перемиканням ми мали попередні попередні повідомлення.

Тижні? Заміна контролю джерела - велика справа. Повинні були бути місяці попередження, що призводять до подібних змін.

За кількома винятками, більшість моєї команди досі не має уявлення про те, як працює Git.

Отже, ваша компанія перейшла на систему управління джерелами, яку мало хто, якщо хто, зрозумів у той час?

Якщо немає іншого контексту, здається, що весь хід був продуманий (хода, а не вибір - я величезний фанат git).

Ми впроваджували Git там, де я працюю, і, природно, був опір. Це було для нового проекту, тому ми зараз підтримуємо два сховища.

Частина проблеми полягає в тому, що люди не побачать переваг переходу на інший SCM, коли той, який вони використовували, працює для них. Це допомогло, коли ми сіли з нашою командою на кількагодинних сеансах, де ми просто показували б використання випадків наших проектів і як Git полегшив це. Наприклад, речі, які нам допомогли:

• Місцеві відділення для заохочення експерименту
• Git bisect, щоб легко відслідковувати помилки
• часті вчинення, не перебиваючи інших
• Швидке перемикання між гілками

та ін. Кожен із них вирішив проблему, з якою ми стикалися з нашою попередньою SCM, і тому люди могли більше цінувати Git.

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

Отже, як "експерт з Git", ви повинні сісти і зробити його максимально простим для використання. Вони хочуть писати код, а не возитися зі своєю системою SCM.

CLI у Git - це криптовалюта і тривіальні проблеми (для вас і я) будуть заважати людям працювати. Ось що сталося з нашою командою (пам’ятайте, це досить грамотні розробники):

• Git із SSH у Windows був поширеною проблемою.
• Люди би тягнули, зливались, але не штовхали злиття. Тож графік був би величезним заплутаним безладом
• Проблема продуктивності в Windows змушує "статус git" тривати 15 секунд
• Не вдалося зрозуміти, як вивести нову гілку. Вони б робили "git checkout -b", який відганяв би все, над чим вони працювали
• EGit в затемненні мав надзвичайне меню. На завершення говорив усім спочатку використовувати командний рядок
• Виходячи з попереднього пункту, об’єднання та налаштування git mergetool
• Плутати в розбіжності між "git add" та "git commit" та "git push".

Ми все ще отримуємо певний опір, але люди точно можуть побачити переваги. Життєво важливо мати декількох людей з Git для керівництва та бути готовими допомогти. Також я б уникав викладати цікаві речі, такі як скидання / перезавантаження / - зміни / тощо. оскільки більшість людей використовуватиме Git як SVN, краще дозволити їм відкрити його, якщо вони цього хочуть.

Професійні проти Git-манії

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

Чому це важливо (так багато)

Інструменти контролю над джерелами є критичними, оскільки неправильне використання може сповільнити не одну людину, а цілу команду. Неправильне використання Git має бути менш проблематичним, ніж використання SVN, CVS та інших систем. Історично склалося, що невміле використання систем із блокуванням файлів було особливо проблематичним, і компанії найняли дискретні команди для складання, щоб коли хтось потрапив у біду, був вільний експерт, який майже нічого не робив, крім контролю джерел, який міг приїхати вилікувати рану до сховища. Це частково пояснює частину пристрасті, яку ви виявляєте за git.

Як виглядає базове знання?

Деякі конкретні критерії включають:

• Без посилання на документацію:

  • Можна додавати файли, вносити зміни, натискати та тягнути оновлення.
  • Можна переглядати стан та активність перегляду.
  • Може розгалужуватися та об’єднуватися швидко та без введення помилок.
  • Може користуватися замовленням належним чином.
  • Створіть коментарі, які відповідають коментарям групи.
  • Різні зміни між робочою копією та архівом.

• З документацією:

  • Додайте користувачів та облікові дані для місцевого репо.
  • init місцевий репо.
  • Адміністрація віддаленого репо.
  • Налаштуйте ігноровані файли, генеруйте пара PKI публічних / приватних ключів.
  • Переміщення та видалення файлів.
  • Використовуйте бісект, щоб знайти зміни, які внесли певну помилку.

Суттєва ментальна модель git та керований код є критично важливим для уникнення помилок.

Що ви додали для підвищення кваліфікації / досвіду?

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

Завжди знайдуться члени вашої команди, які стануть енергокористувачами і використовуватимуть майже кожну команду майже з усіма параметрами. Моя рекомендація полягає в тому, щоб членів команди рекомендували продовжувати навчатись (та інші інструменти), поки рентабельність для навчання не опуститься нижче вартості робити щось інше в проекті, головне обмеження - тримати в курсі присвоєння спалених предметів із поточного спринт.

GIT - це справедливий інструмент для виконання роботи, і одна з його найбільших проблем полягає в тому, що багато євангелістів GIT очікують, що всі користувачі GIT стануть під експертами капелюшка, розуміючи найкращі моменти роботи. Це найбільша слабкість GIT - щоб користуватися ним, потрібно знати, як він працює. Рецептів з GIT немає, очікується, ви будете експертом з GIT або не будете використовувати його. Чудово, що ви читаєте Pro-GIT, що ваша організація потребує "goto" гуру GIT (або двох), щоб максимізувати інвестиції в неї, адже не кожен розробник хоче стати GIT Guru - і це нормально.

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

Я не даю мавпам, як працює GIT, доки я знаю, як змусити Git працювати для мене.

Так.

Незалежно від того, про який інструмент вирішила «компанія», ваша команда розробників повинна витратити певний час на вивчення правильного використання інструменту. Ніщо не шкодить продуктивності більше, ніж купу розробників, які бояться чи не знають інструменту. Якщо вони неправильно використовують або працюють проти цього, виникнуть проблеми, і, як піти до хлопця, перед вами постане завдання прибирати безлад.

Git - важкий перехід для багатьох, тому обов'язкове тренування присідання може бути в порядку. Це має допомогти вирішити багато проблем, які виникають у людей.

Я використовував Git лише в особистому середовищі, а не в професійному, і хоча мені подобається потужність, яку він має, і ідея більш децентралізованого управління джерелами, у нього виникають великі проблеми. У Git є протікаюча абстракція, і вона потребує декількох команд для виконання простих речей (наприклад, для внесення змін: git add, git počin, а потім git push). Також дещо з документації бракує та / або плутає, як, наприклад, з описом команди rebase ... "Локальний перехідний порт посилається на оновлену головку вище". Я не маю поняття, що це означає, і хоча я тепер знаю, що ти можеш переміщувати коміти і переписувати історію за допомогою неї (черговий роздратування ... чому ти повинен дозволити це робити ???) Я б ніколи не здогадувався про це з цієї команди опис. Я думаю, що читання з боку вашої команди, а ще кілька тренувань, які ви надаєте, є в порядку.

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

Немає; Я думаю, що розумно очікувати наступного:

1. Виконайте повсякденні завдання (виконайте, штовхайте, тягніть, розгалужуйте, зливайте, розбиваєте тощо) без тримання рук.
2. Виконуйте позапланові завдання без повторних інструкцій. (Кілька повторень нормально - я маю зустріти когось 2-3 рази, перш ніж їх ім’я дійсно прилипне.)

Якщо вони не можуть зробити №1, то, можливо, навчальної частини вашого розіграшу було недостатньо. Якщо вони не можуть зробити №2, то спочатку переконайтесь, що ви пояснюєте досить чітко, перш ніж занадто засмучуватися.