10 речей, які я ненавиджу в Git; Блоги Стіва Беннета

Конфіденційність та файли cookie

Цей сайт використовує файли cookie. Продовжуючи, ви погоджуєтесь на їх використання. Дізнайтеся більше, зокрема, як керувати файлами cookie.

блоги

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

1. Складна інформаційна модель

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

2. Божевільний синтаксис командного рядка

Синтаксис командного рядка абсолютно довільний і непослідовний. Деякі "ярлики" прикрашаються командами верхнього рівня: "git pull" точно еквівалентно "git fetch", за яким слідує "git merge". Але ярлик для “git branch” у поєднанні з “git checkout”? “Git checkout -b”. Вказівка ​​імен файлів повністю змінює семантику деяких команд (“git commit” ігнорує локальні, нестадійні зміни у foo.txt; “git commit foo.txt” - ні). Різні варіанти “git reset” роблять абсолютно різні речі.

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

3. Скандальна документація

Сторінки з людьми - це одне всемогутнє "нахуй". Вони описують команди з точки зору інформатика, а не користувача. Приклад:

git-push - Оновлення віддалених посилань разом із пов’язаними об’єктами

Ось опис для людей: git-push - завантажте зміни з локального сховища у віддалене сховище

Оновлення, інший приклад: (спасибі cgd)

git-rebase - локальний коміт переадресації порту до оновленої верхівки вище

Переклад: git-rebase - послідовно регенерувати серію комітів, щоб їх можна було застосувати безпосередньо до головного вузла

4. Розповсюдження інформаційної моделі

Пам'ятаєте складну інформаційну модель на кроці 1? Він продовжує зростати, як рак. Продовжуйте використовувати Git, і більше концепцій час від часу випадатимуть з неба: посилання, теги, перезапис, комміти вперед, відключений стан голови (!), Віддалені гілки, відстеження, простори імен

5. Дірява абстракція

  1. Знайдіть основу злиття між вашою гілкою та майстром: ‘git merge-base master yourbranch’
  2. Припускаючи, що ви вже внесли свої зміни, перебазуєте своє комітування на базу злиття, а потім створіть нову гілку:
  3. git rebase - to HEAD

1 ГОЛОВА

  • git checkout -b моя-нова-гілка
  • Оформіть свою гілку ruggedisation і видаліть щойно перебазований коміт: ‘git reset –hard HEAD

    1 ’

  • Об’єднайте свою нову гілку назад у міцність: „git merge my-new-branch”
  • Checkout master (‘git checkout master’), об’єднайте нову гілку в (‘git merge my-new-branch’) і перевірте, чи працює вона при об’єднанні, а потім видаліть об’єднання (‘git reset –hard HEAD

    1 ’).

  • Натисніть нову гілку («git push origin my-new-branch») і зареєструйте запит на витяг.