Ця відповідь намагається розглянути питання про те, як зацікавити старших програмістів git, а не про те, як gitнайшвидше навчитися - для цього чудова книжка з git чудова, або будь-яка кількість навчальних посібників (=> Google). Хорошими посиланнями на цю відповідь є Git - це суто функціональна структура даних або особливо коротка Як git зберігає ваші дані .
Боюся, що я маю на це досить похмурий погляд. Я був саме у вашому взутті - я gitботанік і хотів перетворити команду подалі від svn, давайте поглянемо, недостовірні результати. У моєму випадку це призвело до того, що я активно змінюю своє власне сприйняття і приймаю, що люди просто не можуть бути «змушені до щастя». Люди - це не комп’ютери, програмувати їх неймовірно важко. Я все ще радий тому, що спробував, він досить м'яко показав мені те, чим я займаюся і чим не хочу займатися у своєму професійному житті.
Є люди, які починають мотивуватися, коли залучаються нові речі, і є такі, хто вмотивований. Це не має нічого спільного git, але gitконкретно у вас завжди виникає ефект "навіщо нам взагалі його використовувати, якщо svnце просто добре?", Що є масовим психологічним бар'єром.
Крім того, для справжнього майстерності gitпотрібен інтенсивний інтерес до абстрактних структур даних. Це може здатися неймовірним, але, на мій досвід, є програмісти, які взагалі не мають такого інтересу і які нудьгують і перевантажують елементи складніші, ніж прості масиви. Ви можете сперечатися вперед і назад, чи повинні вони робити ту роботу, яку вони роблять, але це так і є.
Якщо люди не зацікавлені в цьому, вони не зрозуміють цього. Простий і простий. Я б став до того, що незацікавленість є основною причиною поганих оцінок у школі, не пропускаючи інтелекту.
Однак це було б навчальним планом, як я застосовував би його, базуючись на накопиченні знань знизу вгору. Це не спрацювало для мене, але ти можеш сприймати це як натхнення, щоб провалити своє.
GUI
Хоча наступний підхід не обов'язково потребує підтримки графічного інтерфейсу для дій ( git addу сховищі світового привіт ...), він надзвичайно допомагає мати графічний інтерфейс для візуалізації сховища з самого початку. Якщо ви не можете вирішити, яким чином скористатись, скористайтеся gitkв крайньому випадку. Якщо ваші хлопці використовують будь-який візуальний редактор, знайдіть їх gitграфічний інтерфейс.
Ключовою є (статична) структура даних
Почніть з пояснення внутрішніх типів даних (їх є лише три-плюс-один: блоби, дерева, коміти, анотовані теги, остання з яких на цьому етапі не хвилює) та їх структуру. Ви можете легко зробити це на дошці / олівцем; дерево легко малювати, оскільки його ніколи не можна змінити, ви можете буквально просто додавати речі весь час. Ви можете зробити ігровий сеанс у щойно створеному локальному сховищі та використати git cat-fileдля перегляду фактичних об’єктів, щоб показати їм, що вони насправді такі тривіальні, як рекламовані.
Якщо ви можете допомогти їм зрозуміти це
- ... в історії є буквально лише 3 типи об'єктів, усі вони дуже прості, майже тривіальні та
- ... більшість
gitпідкоманд просто «масажують» ті об’єкти так чи інакше, причому майже тривіальними операціями (в основному, є лише одне: десь додайте нове фіксування), і ...
- ... все легко можна побачити прямо перед вами з
lsта git cat-file...
тоді вони матимуть ментальний переклад того, що є насправді у сховищі. У цей момент люди похилого віку можуть пам’ятати, що внутрішні органи - svnце таємна магія (коли-небудь виникали проблеми із замками всередині сховища svn, або із «реінтегруючими» гілками тощо?), І це може просто їх трохи мотивувати.
Одна з проблем, зокрема людей, які раніше звикли svn, - звикнути до думки, що одним фіксом (об'єктом, а не дією) завжди є все дерево директорій. В svn, люди використовуються для здійснення окремих файлів. Це кардинально інший підхід. О, і той факт, що той самий термін "фіксування" використовується і для статичного об'єкта, і дія теж не допомагає.
Інша проблема для svnхлопців полягає в тому, що svnвикористовується лінійна історія, а не дерево. Це, знову ж таки, дико інакше. Тож саме час дуже багато вказати на ці відмінності .
Дії, пояснені з точки зору структури
Коли вони зрозуміли, з яких частин складається gitсховище, настав час показати їм саме те, що gitроблять окремі підкоманди щодо них.
Я говорю про add, commitв поєднанні з локальним робочим каталогом і етапом (переконайтеся, що вони розуміють, що робочий каталог не є тим самим, як область постановки, яка не збігається з сховищем).
Коли вони зрозуміли, що ці команди просто вирощують дерево (яке, знову ж таки, на цьому етапі складається з 3-х типів - blobs, дерева, commits, а не тільки comits), ви можете зробити перше git pushі git pull(у швидкому режимі вперед! ) показати їм, що gitбуквально лише штовхає його об'єкти навколо, що хеші насправді є лише хешами вмісту, що ви можете легко скопіювати ці речі за допомогою команди копіювання файлової системи тощо.
Очевидно, що тримайтеся далеко від будь-яких несуттєвих варіантів цих команд, ми говоримо git add hello.txtтут.
Гілки
Зауважте, що розгалуження особливо важко для svnлюдей, оскільки воно зовсім інше. svnМодель набагато легше візуалізувати, так як там в основному немає нічого , щоб візуалізувати - це на увазі. gitМодель не так багато. Переконайтеся, що вони знають з самого початку, що гілки та теги - це лише "наліпки", які кудись вказують, а насправді "не існують" з точки зору статичної, непорушної історії.
Потім зробіть приклад за простим прикладом, щоб показати, що ви насправді можете зробити з ними. Як ви самі, здається, звикли git, у вас не повинно виникнути проблем із пошуком мотивації. Переконайтеся, що вони завжди бачать це з точки зору того, як росте дерево.
Якщо у них це вниз, ви можете пояснити, як git pullнасправді git fetch && git merge; як усі репозиторії насправді містять абсолютно однакові об’єкти ( git fetchмайже те саме, що копіювати речі scpвсередині каталогу об’єктів git) тощо.
Ймовірно, якщо до цього часу ви не дотягнулися до того, щоб пробудити їх інтерес, то ви можете так само здатися, але якщо їм вдасться дістатись так далеко, то у них є всі розумові інструменти, і їх має бути мало страх пов'язаний більше. Решта (git workflow ...) повинна бути тоді під гору.
Останні слова
Це звучить як багато зусиль, і це насправді так. Не продайте це як "нам це потрібно для цього проекту", але "це допомагає вам особисто розвиватися і допоможе вам у всіх ваших подальших взаємодіях". Для цього вам потрібно багато часу, а час - це гроші. Якщо ви не маєте на це схвалення керівництва, це може просто не варто; ви можете, можливо, поговорити про це зі своїм начальником.
Якщо ви вирішите відмовитися від навчання розробників, які, схоже, не в змозі зрозуміти це, але ви абсолютно повинні використовуватись gitу майбутньому, подумайте про заміну всієї взаємодії з gitкомандами підготовленими сценаріями або деяким графічним інтерфейсом, який gitпозбавляє всіх особливостей. Перелийте всі сценарії контролю помилок тощо у сценарії та спробуйте налагодити це.