Терминология, используемая Git
Похоже, я должен научиться использовать Git. Что, вероятно, хорошая вещь (ТМ). Однако, читая онлайн-руководства и справочные страницы, я просто не могу разобраться с терминологией. Все всегда определяется с точки зрения их самих или других необъяснимых терминов (сделайте "мужик", и вы поймете, что я имею в виду).
Итак, существует ли более похожая на DAG структура определений терминов, включая некоторые из следующих (все они взяты со страницы справочника git!). Возможно, используя файловую систему в качестве отправной точки, и не предполагая, что читатель хорошо разбирается в svn (а я нет).
- Сделки рЕПО
- хранилище
- мерзавец
- "мерзавец"
- индекс
- клон
- совершить
- ветка
- дерево
- вверх по течению
- голова
- ГОЛОВА
- версия
- тег
- архив
- пластырь
- представление
- ревизия
- копить
- архив
- объект
- модуль
- подмодуль
- refspec
- история
Хотя я могу найти объяснения для некоторых, они обычно с точки зрения другого. Также некоторые другие термины, которые я знаю из других контекстов (например, UNIX diff). Однако некоторые другие, я думал, что я знал...
Я понял, что есть репозитории (похожие на gits? И / или trees? Upstream?), Которые вы копируете (clone? Branch?) Для физического переноса файлов на жесткий диск. Затем существуют ветки (похожие на changesets?), Теги и коммиты (похожие на патчи?), Но их различие не ясно. Какие файлы что изменяют? Что делает мои файлы локальными и что (не дай бог) отправит мой код в интернет?
Каков рекомендуемый способ работы, когда дело доходит до веток, тегов и фиксаций - чтобы можно было легко переключаться между версиями и импортировать обновления из общедоступных gits.
// T, прикусывая язык, чтобы контролировать свое разочарование...
6 ответов
Вот попытка дополнить твой глоссарий (изо всех сил пытаясь использовать мои собственные слова):
репозиторий, репозиторий: это ваша объектная база данных, в которой хранятся ваша история и конфигурация. Может содержать несколько веток. Часто он также содержит рабочее дерево.
мерзавец, "мерзавец": никогда не слышал, извините. "мерзавец", вероятно, описывает само программное обеспечение, но я не уверен
Индекс, область подготовки: это "кэш" между вашим рабочим деревом и вашим хранилищем. Вы можете добавлять изменения в индекс и шаг за шагом создавать свой следующий коммит. Когда ваш индексный контент вам нравится, вы можете создать коммит из него. Также используется для хранения информации во время неудачных слияний (ваша сторона, их сторона и текущее состояние)
клон: клон репозитория ("просто другой репозиторий") или сам акт ("клонирование репозитория (создает новый клон)")
commit: состояние вашего проекта в определенное время. Содержит указатель на его родительский коммит (в случае слияния: несколько родителей) и указатель на структуру каталогов в данный момент времени.
Отрасль: другая линия развития. Ветка в git - это просто "метка", указывающая на коммит. Вы можете получить полную историю через родительские указатели. Ветвь по умолчанию является локальной только для вашего хранилища.
Дерево: в основном говоря каталог. Это просто список файлов (BLOB-объектов) и подкаталогов (деревьев). (Список также может содержать коммиты, если вы используете подмодули, но это сложная тема)
upstream: после клонирования репозитория вы часто называете этот "оригинальный" репозиторий "upstream". В Git это псевдоним
originзаголовок: верхний коммит ветви (коммит, на который указывает метка)
HEAD: символическое имя для описания текущего извлеченного коммита. Часто самый верхний коммит
версия: может быть такой же, как коммит. Также может означать выпущенную версию вашего проекта.
тег: описательное имя, данное одному из ваших коммитов (или деревьев, или блобов). Также может содержать сообщение (например, журнал изменений). Теги могут быть криптографически подписаны с помощью GPG.
архив: простой архив (.tar, .zip), ничего особенного в git.
patch: коммит, экспортированный в текстовый формат. Может быть отправлено по электронной почте и применено другими пользователями. Содержит исходный файл auther, сообщения о фиксации и различия между файлами
представление: не знаю. Возможно, вы добавили патч в проект?
changeset: синоним слова "commit"
stash: Git позволяет вам "прятать" изменения. Это дает вам чистое рабочее дерево без каких-либо изменений. Позже их можно "выскочить", чтобы вернуть. Это может быть спасением жизни, если вам нужно временно поработать над несвязанным изменением (например, исправление критической ошибки)
объект: может быть одним из
commit,tree,blob,tag, Объект связал свой хэш SHA1, по которому на него ссылаются (фиксация с идентификаторомdeadbeaf, деревоdecaf). Хеш идентичен для всех репозиториев, которые используют один и тот же объект. Это также гарантирует целостность репозитория: вы не можете изменить прошлые коммиты, не изменив хеши всех дочерних коммитов.(модуль,) подмодуль: хранилище, включенное в другое хранилище (например, внешняя библиотека). Продвинутые вещи.
revspec: revspec (или выражение revparse) описывает определенный объект git или набор коммитов через так называемый расширенный синтаксис SHA1 (например,
HEAD,master~4^2,origin/master..HEAD,deadbeaf^!…)refspec: refspec - это шаблон, описывающий сопоставление между удаленными и локальными ссылками во время операций Fetch или Push.
история: Описывает все коммиты предка до коммита, возвращающегося к первому коммиту.
Вещи, которые вы не упомянули, но, вероятно, полезно знать:
Все, что вы делаете, является локальным для вашего хранилища (либо создается git init или же git clone git://url.com/another/repo.git). В git есть только несколько команд, которые взаимодействуют с другими репозиториями (aka teh interwebz), включая clone, fetch, pull, push,
Push & pull используются для синхронизации хранилищ. Тянуть fetches объекты из другого хранилища и объединяет их с вашей текущей веткой. Push используется для принятия ваших изменений и push их в другой репозиторий. Вы не можете выдвигать отдельные коммиты или изменения, вы можете только выдвинуть коммит, включая его полную историю.
Один репозиторий может содержать несколько веток, но в этом нет необходимости. Ветвь по умолчанию в git называется master, Вы можете создать столько веток, сколько захотите, слияние - это кусок пирога с git. Филиалы являются локальными, пока вы не запустите git push origin <branch>,
Фиксация описывает полное состояние проекта. Эти состояния можно сравнивать друг с другом, что дает "diff" (git diff origin/master master = увидеть разницу между origin/master а также master)
Git довольно мощный, когда дело доходит до подготовки ваших коммитов. Ключевым ингредиентом здесь является "индекс" (или "область подготовки"). Вы можете добавить отдельные изменения в индекс (используя git add), пока вы не думаете, что индекс выглядит хорошо. git commit запускает ваш текстовый редактор, и вам необходимо предоставить сообщение о коммите (почему и как вы сделали это изменение); после ввода сообщения о коммите git создаст новый коммит, содержащий содержимое индекса, поверх предыдущего коммита (родительский указатель - SHA1 предыдущего коммита).
Git поставляется с документацией именно для того, что вы ищете.
$ git help glossary
Я нашел эту (бесплатную) книгу очень полезной, когда узнал, как использовать git: http://progit.org/. Книга существует и в печатном виде.
Я думаю, что самый быстрый способ выучить git - это взять книгу или учебник, который научит вас основным понятиям и терминам.
Еще один хороший ресурс для изучения Git - Git Immersion от Edgecase. Пытаться изучать Git на страницах man, вероятно, очень сложно, есть короткая, крутая кривая обучения, которую нужно преодолеть в первую очередь. Сначала вам нужно познакомиться с концепцией DCVS (распределенной системы контроля версий).
Progit, как рекомендует @fulhack, тоже очень хорош.
Я также настоятельно рекомендую Think Like A Git. Объяснение перебазирования здесь на вес золота.
Лучшее, что я нашел для понимания мерзавца - Притча о мерзавцах
Представьте, что у вас есть компьютер, на котором нет ничего, кроме текстового редактора и нескольких команд файловой системы. Теперь представьте, что вы решили написать большую программу на этой системе. Поскольку вы являетесь ответственным разработчиком программного обеспечения, вы решаете, что вам нужно изобрести какой-то метод отслеживания версий вашего программного обеспечения, чтобы вы могли получить код, который вы ранее изменили или удалили. Далее следует история о том, как вы могли бы спроектировать одну из таких систем контроля версий (VCS), и обоснование этих вариантов дизайна...
Я думаю, что вам может понравиться эта статья: Git для компьютерных ученых
И еще один важный аспект, который нужно понимать при использовании git, - это рабочий процесс. Прочитайте этот замечательный пост в блоге: модель ветвления Git