Git Explained: для начинающих

Я работаю с Git уже около двух лет, но только для своих личных проектов и проектов, которые у меня есть на GitHub. На работе мы все еще используем TFS и SVN (на данный момент). Недавно Паоло Перротта пришел в нашу компанию, чтобы провести курс по гибкому планированию, и, поскольку Git был довольно новым для большинства моих партнеров, он также быстро объяснил Git в контексте рефакторинга. Мне очень понравился его подход к объяснению, и поэтому я хотел бы повторить его объяснение здесь.

Как раз перед тем, как мы начнем ..

Чем Git отличается от других VCS (систем контроля версий)? Вероятно, наиболее очевидное различие заключается в том, что Git распространяется (в отличие, например, от SVN или TFS). Этот

означает, что у вас будет локальный репозиторий, который находится в специальной папке с именем .git и у вас обычно (но не обязательно) будет удаленный центральный репозиторий, куда разные соавторы могут вносить свой код. Обратите внимание, что каждый из этих участников имеет точный клон хранилища на своей локальной рабочей станции.

Сам Git может быть представлен как нечто, что находится поверх вашей файловой системы и манипулирует файлами. Более того, вы можете представить Git в виде древовидной структуры, в которой каждый коммит создает новый узел в этом дереве. Практически все команды Git служат для навигации по этому дереву и для управления им соответствующим образом. Поэтому в этом уроке я хотел бы взглянуть на то, как работает Git, просмотрев репозиторий Git с точки зрения дерева, которое он создает. Для этого я иду через некоторые распространенные случаи использования, такие как

• добавление / изменение нового файла
• создание и объединение веток с конфликтами слияния и без них
• Просмотр истории / журнала изменений
• Выполнение отката до определенного коммита
• Совместное использование / синхронизация вашего кода в удаленном / центральном хранилище

терминология

Вот терминология git:

• master — основная ветка хранилища. В зависимости от рабочего процесса, это тот, над кем работают люди, или тот, где происходит интеграция.
• клон — копирует существующий репозиторий git, обычно из какого-то удаленного места в вашу локальную среду.
• commit — отправка файлов в хранилище (локальное); в других VCS это часто упоминается как «регистрация»
• Получить или получить — это как «обновить» или «получить последнюю» в других VCS. Разница между извлечением и извлечением заключается в том, что извлечение сочетает в себе как получение самого последнего кода из удаленного репо, так и выполнение слияния.
• push — используется для отправки кода в удаленный репозиторий
• remote — это «удаленные» местоположения вашего хранилища, обычно на каком-то центральном сервере.
• SHA — каждый коммит или узел в дереве Git идентифицируется уникальным ключом SHA. Вы можете использовать их в различных командах, чтобы управлять конкретным узлом.
• head — это ссылка на узел, на который в данный момент указывает наше рабочее пространство хранилища.
• ветвь — так же, как в других VCS, с той разницей, что ветвь в Git на самом деле не более особенная, чем конкретная метка на данном узле. Это не физическая копия файлов, как в других популярных VCS.

Настройка рабочей станции

Я не хочу вдаваться в детали настройки вашей рабочей станции, поскольку существует множество инструментов, которые частично различаются на разных платформах. Для этого поста я выполняю все операции в командной строке. Даже если вы не мошенник, вам стоит попробовать (это никогда не повредит). Для настройки командной строки Git access просто перейдите на git-scm.com/downloads, где вы найдете необходимые загрузки для вашей ОС. Более подробную информацию можно найти и здесь . После того, как все настроено и у вас есть «git» в переменной окружения PATH, первое, что вам нужно сделать, это настроить git с вашим именем и адресом электронной почты:

Начнем: создайте новый Git-репозиторий

Прежде чем начать, давайте создадим новый каталог, в котором будет находиться репозиторий git, и cd в него:

Теперь мы готовы инициализировать новый git-репозиторий.

Мы можем проверить текущее состояние git-репозитория, используя

Создать и зафиксировать новый файл

Следующим шагом является создание нового файла и добавление в него некоторого содержимого.

Опять же, проверка статуса теперь показывает следующее

Чтобы «зарегистрировать» файл для фиксации, нам нужно добавить его в git, используя

Проверка состояния теперь указывает, что файл готов к фиксации:

Теперь мы можем зафиксировать это в хранилище

Обычной практикой является использование «присутствия» в сообщениях коммитов. Поэтому вместо того, чтобы писать «добавил мой первый файл», мы пишем «добавить мой первый файл». Так что, если мы сейчас отступим на секунду и посмотрим на дерево, у нас будет следующее.

Есть один узел, на который указывает мастер «label».

Добавить другой файл

Добавим еще один файл:

Кстати, обратите внимание, что на этот раз я использовал git add . который добавляет все файлы в текущем каталоге ( . ). С точки зрения дерева у нас теперь есть другой узел, и мастер перешел к этому.

Создать (особенность) ветку

Ветвление и слияние — это то, что делает Git настолько мощным и для чего он был оптимизирован, будучи распределенной системой контроля версий (VCS). Действительно, ветки функций довольно популярны для использования с Git. Ветви компонентов создаются для каждого нового вида функций, которые вы собираетесь добавить в свою систему, и они обычно удаляются после того, как функция возвращается обратно в основную ветку интеграции (обычно это основная ветка). Преимущество состоит в том, что вы можете экспериментировать с новыми функциями в отдельной изолированной «игровой площадке» и быстро переключаться назад и вперед к исходной «основной» ветке, когда это необходимо. Более того, его можно легко снова удалить (если он не нужен), просто отбросив ветку функций. Но давайте начнем. Прежде всего я создаю новую функциональную ветку:

проведение

мы получаем список филиалов. Знак * перед master указывает, что мы в данный момент находимся в этой ветви. Вместо этого перейдем к my-feature-branch :

Еще раз

Обратите внимание, что вы можете напрямую использовать команду git checkout -b my-feature-branch для создания и извлечения новой ветки за один шаг. Отличие от других VCS в том, что существует только один рабочий каталог . Все ваши ветки живут в одном и том же, и нет отдельной папки для каждой создаваемой вами ветки. Вместо этого, когда вы переключаетесь между ветвями, Git заменит содержимое вашего рабочего каталога так, чтобы оно совпадало с тем, в котором вы переключаетесь. Давайте изменим один из наших существующих файлов

… а затем передайте его в наш новый филиал

Обратите внимание , что на этот раз я использовал git commit -a -m чтобы добавить и зафиксировать модификацию за один шаг. Это работает только для файлов, которые уже были добавлены в Git Repo ранее. Новые файлы не будут добавлены таким образом и требуют явного git add как показано ранее. Как насчет нашего дерева?

Пока что все кажется довольно нормальным, и у нас все еще есть прямая линия в дереве, но обратите внимание, что теперь master остался там, где он был, и мы двинулись вперед с my-feature-branch . Вернемся к мастеру и изменим там же файл.

Как и ожидалось, hallo.txt не hallo.txt :

Давайте изменим и передадим его на master (это позже вызовет хороший конфликт ).

Наше дерево теперь визуализирует ветку:

Слияние и разрешение конфликтов

Следующим шагом будет объединение нашей ветки функций обратно в master . Это делается с помощью команды слияния

Как и ожидалось, у нас есть конфликт слияния в hallo.txt .

Позволяет решить это:

..и затем совершить это

Дерево отражает наше слияние.

Перейти к определенному коммиту

Предположим, мы хотим вернуться к данному коммиту. Мы можем использовать команду git log чтобы получить все идентификаторы SHA, которые уникально идентифицируют каждый узел в дереве.

Возьмите один из идентификаторов (также, если он не весь, это не имеет значения) и перейдите на этот узел с помощью команды checkout

Обратите внимание на комментарий, который выводит git. Что это значит? Отделенная голова означает, что «голова» больше не указывает на «метку» ветви, а на конкретный коммит в дереве. Вы можете думать о ГОЛОВКЕ как о «текущей ветви». Когда вы переключаете ветки с помощью git checkout , ревизия HEAD изменяется, чтобы указывать на вершину новой ветки. … HEAD может ссылаться на конкретную ревизию, которая не связана с именем ветви. Эта ситуация называется отделенной ГОЛОВОЙ . Stackoverflow Post Обычно, когда я изменяю hallo.txt и фиксирую изменения, дерево выглядит следующим образом:

Как видите, у вновь созданного узла нет метки. Единственная ссылка, которая в настоящее время указывает на это, является head . Однако, если мы теперь переключимся на master снова, предыдущий коммит будет потерян, так как у нас нет возможности вернуться назад к этому узлу дерева.

И на самом деле, Git так любезно, чтобы напомнить нам об этом факте. Теперь дерево выглядит снова, как на рисунке 6.

отмена

Переход назад — это хорошо, но что, если мы хотим отменить все обратно в состояние до слияния ветви функции? Это так же просто, как

Общий синтаксис здесь: git reset --hard <tag/branch/commit id> .

Совместное использование / синхронизация вашего репозитория

В конечном итоге мы хотим поделиться нашим кодом, обычно синхронизируя его с центральным хранилищем. Для этого нам нужно добавить пульт .

Чтобы увидеть, удалось ли мне, просто введите:

который перечисляет все добавленные пульты. Теперь нам нужно опубликовать нашу локальную ветку master в удаленном хранилище. Это сделано как

И мы сделали. По-настоящему мощным является то, что вы можете добавить несколько разных пультов. Это часто используется в сочетании с решениями облачного хостинга для развертывания вашего кода на вашем сервере. Например, вы можете добавить удаленный сервер с именем «deploy», который указывает на некоторый репозиторий сервера облачного хостинга, например

а затем всякий раз, когда вы хотите опубликовать свою ветку, вы выполняете

клонирование

Точно так же это работает, если вы хотите начать с существующего удаленного хранилища. Первый шаг, который необходимо сделать, это «извлечь» исходный код, который называется клонированием в терминологии Git. Так что мы бы сделали что-то вроде

Это создаст папку (в данном случае) с именем «intro.js», и если мы введем ее

и проверим для удаленных мы видим, что соответствующая информация отслеживания удаленного хранилища уже настроена

Теперь мы можем запустить цикл commit / branch / push как обычно.

Ресурсы и ссылки

Сценарии, приведенные выше, были простыми, но в то же время, вероятно, и наиболее используемыми. Но есть намного больше, на что способен Git. Чтобы получить более подробную информацию, вы можете обратиться по ссылкам ниже.

• http://gitready.com/
• Книга: Pro Git Скотта Чакона
• Попробуй Git за 15 минут
• Введение в Git со Скоттом Чаконом из GitHub
• Мой личный Git Cheat Sheet, куда я постоянно добавляю то, что хочу запомнить