Введение в Git. Что это такое и как использовать?
Git — это распределенная система контроля версий с открытым исходным кодом. Описание довольно сложное, давайте разберем его по частям:
Зачем вообще нужны системы контроля версий?
В реальном мире над проектами обычно параллельно трудятся сразу несколько разработчиков. Так как они имеют дело с одним и тем же кодом, при его изменении возможны конфликты. Git позволяет решать эту проблему.
Кроме того, часто изменяются требования к продукту. С системой контроля версий легко отменить внесенные изменения и вернуться к более старой версии.
И наконец, иногда требуется объединить в одну кодовую базу несколько параллельных проектов. В этом очень помогает концепция веток в Git.
Начинаем использовать Git
Установка
Здесь вы найдете детальную инструкцию по установке Git на любую операционную систему.
Проверьте установку, запустив в терминале команду
Создание локального репозитория
Зайдите в нее и добавьте локальный git-репозиторий с помощью следующих команд:
Немного кода
Создайте новый файл demo.txt в папке проекта и запишите в него что-нибудь:
Вместо реального кода мы будет работать с обычным текстом. Это поможет сосредоточиться на концепциях Git, не отвлекаясь на специфические особенности языков программирования.
Работа с кодом и сохранение изменений
Добавление порции кода в локальный репозиторий называется коммитом, или фиксацией. До коммита код находится в «рабочей» или «промежуточной» области (staging area). Здесь можно отслеживать все файлы, которые должны быть зафиксированы.
Файлы, которые не добавлены в промежуточную область, не могут быть зафиксированы.
Добавление в рабочую область (staging)
Для добавления файла в промежуточную область используется следующая команда:
Можно добавить сразу несколько:
Чтобы добавить все файлы внутри директории проекта, используйте:
Обращайтесь с этой командой осторожно, так как она действительно добавляет ВСЕ файлы и папки в промежуточную область.
Фиксация изменений (commiting)
Чтобы сделать коммит, нужно выполнить команду:
«Initial Commit» — это сообщение фиксации. Используйте понятные и отражающие суть изменений сообщения.
Git status и git log
Теперь изменим demo.txt :
Статус
git status показывает, какие файлы были изменены и какие файлы находятся в промежуточной области. Команда выводит и другую информацию, которую мы пока можем проигнорировать.
Мы увидим, что demo.txt изменен, но еще не находится в рабочей области. Давайте добавим его:
и зафиксируем изменения:
Команда git log напечатает все сделанные коммиты вместе с их автором, датой и сообщением.
Ветки
До сих пор мы не создали ни одной ветки в Git. По умолчанию все коммиты попадают в ветку master.
Что такое ветка?
Зачем нужно создавать несколько веток?
Разные ветки позволяют параллельно разрабатывать разную функциональность.
Изначально commit 1 и commit 2 выполнялись в ветке master. После второй фиксации создается новая ветка под названием test, и commit 3 и commit 4 добавляются в нее.
Создайте новую ветку в локальном репозитории
Ветка создана, но мы все еще находимся в контексте ветки master. Чтобы переключиться на тестовую, нужно использовать команду
Увидеть полный список все веток локального репозитория поможет команда
Сделайте коммиты в новой ветке
Добавьте изменения в рабочую область и зафиксируйте их:
После этого коммита тестовая ветка опережает главную: она включает две ранее сделанные фиксации и одну новую.
Вы можете проверить историю коммитов в тестовой ветке, используя:
Слияние
Предположим, мы закончили какой-то этап разработки в тестовой ветке и теперь хотим вернуть весь код в главную, то есть объединить их (смержить).
Сначала вернитесь в ветку master:
Затем выполните команду merge :
Слияние должно быть успешным, так как в этом примере нет конфликтов кода. Но в реальных проектах они иногда возникают. Умение разрешать конфликты слияния приходит с опытом.
Запустите git log и вы увидите, что в мастер-ветке теперь также 3 коммита.
Удаленный Репозиторий
До сих пор мы работали только в локальном репозитории. Обычно так и происходит: разработчик пишет код на своем компьютере. Но затем он должен отправить свои изменения в удаленный репозиторий, чтобы их могли увидеть другие разработчики.
GitHub
Для создания удаленного репозитория мы будем использовать GitHub. Прежде всего вам нужно создать аккаунт.
После регистрации нажмите на кнопку Начать проект, чтобы создать новый репозиторий. Дайте ему имя git-blog-demo и нажмите кнопку Создать репозиторий.
На изображении выделен URL вашего репозитория, который вы должны увидеть на странице.
Чтобы указать вашему локальному репозиторию на удаленный, используйте следующую команду (вместе [repository url] введите адрес своего репозитория без квадратных скобок):
Git push
Теперь отправим весь код из локального репозитория в удаленный:
Он будет помещен из ветки master локального репозитория в ветку master удаленного репозитория.
Дополнительные команды
Git pull
Используется для извлечения последних изменений из удаленного репозитория в локальный. Удаленный код может обновляться другими разработчиками, поэтому необходимо поддерживать локальную версию в актуальном состоянияя:
Git clone
Используется для клонирования существующего удаленного репозитория на ваш компьютер.
Поздравления
Теперь вы знаете основы использования Git и можете переходить к более продвинутым концепциям!
Введение в Git: от установки до основных команд
Авторизуйтесь
Введение в Git: от установки до основных команд
Введение в Git — это почти всегда пошаговая инструкция, но не всегда достаточно понятная. Именно поэтому мы дополнили гайд схемами, которые сделают информацию максимально доступной.
Примечание Вы читаете улучшенную версию некогда выпущенной нами статьи.
Основы Git
Git — это система контроля версий (VCS), которая позволяет отслеживать и фиксировать изменения в коде: вы можете восстановить код в случае сбоя или откатить до более ранних версий. А ещё это must-have инструмент для взаимодействия нескольких разработчиков на одном проекте. Подробнее об этом в руководстве по командной разработке с Git.
Установка Git
Настройка конфигурационного файла
Первое, что нужно сделать, — настроить имя пользователя и email для идентификации. Эти настройки хранятся в конфигурационном файле.
3–5 декабря, Онлайн, Беcплатно
Создаём Git-репозиторий
Коммиты
Основы работы с Git предполагают понимание коммитов. Команда git commit откроет текстовый редактор для ввода сообщения коммита. Также эта команда принимает несколько аргументов:
Советы для эффективного введения в Git:
История коммитов в Git
Коммиты хранят состояние файловой системы в определённый момент времени и указатели на предыдущие коммиты. Каждый коммит содержит уникальную контрольную сумму — идентификатор, который Git использует, чтобы ссылаться на коммит. Чтобы отслеживать историю, Git хранит указатель HEAD, который указывает на первый коммит (мы следуем по цепочке коммитов в обратном порядке, чтобы попасть к предыдущим коммитам).
Мы можем ссылаться на коммит либо через его контрольную сумму, либо через его позицию относительно HEAD, например HEAD
4 ссылается на коммит, который находится 4 коммитами ранее HEAD.
Файловая система Git
Git отслеживает файлы в трёх основных разделах:
Все основные команды по работе с файлами сводятся к пониманию того, как Git управляет этими тремя разделами. Существует распространённое заблуждение, что область подготовленных файлов только хранит изменения. Лучше думать об этих трёх разделах как об отдельных файловых системах, каждая из которых содержит свои копии файлов.
Просмотр изменений в файловых системах
Команда git status отображает все файлы, которые различаются между тремя разделами. У файлов есть 4 состояния:
Примечание Файл может быть одновременно в состоянии «изменён» и «подготовлен», если версия в рабочей директории новее, чем в области подготовленных файлов, которая в свою очередь новее версии в HEAD.
Чтобы посмотреть сами изменения, а не изменённые файлы, можно использовать следующие команды:
Обновление файловых систем
Команда git add обновляет область подготовленных файлов версиями файлов/папок из рабочей директории.
Команда git commit обновляет HEAD новым коммитом, который делает снимки файлов в области подготовленных файлов.
Действие команды git reset состоит из трёх потенциальных шагов:
С другой стороны, git checkout (уже без HEAD) перезаписывает версию файла в рабочей директории версией в области подготовленных файлов, то есть отменяет изменения с момента последней подготовленной версии.
Игнорирование файлов
Зачастую нам не нужно, чтобы Git отслеживал все файлы в репозитории, потому что в их число могут входить:
Просмотр изменений
Удалённые репозитории
При использовании команды git clone мы не только загружаем себе копию репозитория, но и неявно отслеживаем удалённый сервер, который находится по указанному адресу и которому присваивается имя origin.
Наиболее употребляемые команды:
Следующие команды работают с удалёнными ветками:
Таким образом несколько людей могут запрашивать изменения с сервера, делать изменения в локальных копиях и затем отправлять их на удалённый сервер, что позволяет взаимодействовать друг с другом в пределах одного репозитория.
GitHub
GitHub — это платформа, которая хранит Git-репозитории на своих серверах, и основы распределенной системы управления версиями Git подразумевает умение с ней работать. Вы можете хранить свои удалённые репозитории или участвовать в Open Source проектах на GitHub.
Да, есть и другие платформы, но GitHub идеален для введения в Git и дополняет VCS новыми возможностями.
После этого вам может понадобиться слить тематическую ветку вашего удалённого репозитория в основную ветку оригинального. Для этого вы можете создать новый Pull Request — запрос на внесение изменений, где GitHub проверяет наличие конфликтов прежде чем повзолить вам провести слияние. Зачастую существуют и другие проверки перед слиянием, например просмотр и одобрение кода или даже запуск тестов. В запросе можно обсудить код, а все коммиты, которые вы отправляете в удалённую тематическую ветку, будут автоматически добавлены в запрос, даже если он был создан до этих коммитов.
Работа с ветками
Ветвление — это возможность работать над разными версиями проекта: вместо одного списка с упорядоченными коммитами история будет расходиться в определённых точках. Каждая ветвь содержит легковесный указатель HEAD на последний коммит, что позволяет без лишних затрат создать много веток. Ветка по умолчанию называется master, но лучше назвать её в соответствии с разрабатываемой в ней функциональностью.
Итак, есть общий указатель HEAD и HEAD для каждой ветки. Переключение между ветками предполагает только перемещение HEAD в HEAD соответствующей ветки.
Локальный и удалённый репозитории могут иметь немало ветвей, поэтому когда вы отслеживаете удалённый репозиторий — отслеживается удалённая ветка ( git clone привязывает вашу ветку master к ветке origin/master удалённого репозитория).
Привязка к удалённой ветке:
В общем, git checkout связан с изменением места, на которое указывает HEAD ветки, что похоже на то, как git reset перемещает общий HEAD.
Прятки и чистка
Есть одна тонкость — при переключении веток Git требует, чтобы рабочее состояние было чистым, то есть все изменения в отслеживаемых файлах должны быть зафиксированы.
Прим. перев. Это не совсем так. При некоторых обстоятельствах Git может автоматически перенести незафиксированное изменение в другую ветку.
Слияние
Ветку, в которую мы хотим слить изменения, будем называть основной, а ветку, из которой мы будем их сливать, — тематической.
После открытия таких файлов вы увидите похожие маркеры разрешения конфликта:
Замените в этом блоке всё на версию, которую вы хотите оставить, и подготовьте файл. После разрешения всех конфликтов можно использовать git commit для завершения слияния.
Перемещение
Вместо совмещения двух ветвей коммитом слияния, перемещение заново воспроизводит коммиты тематической ветки в виде набора новых коммитов базовой ветки, что выливается в более чистую историю коммитов.
Перемещение vs. слияние
После слияния лог с историей может выглядеть довольно беспорядочно. С другой стороны, перемещение позволяет переписать историю в нормальной, последовательной форме. Но перемещение — не панацея от запутанных логов: перемещённые коммиты отличаются от оригинальных, хотя и имеют одного и того же автора, сообщение и изменения.
Перемещайте изменения только на вашей приватной локальной ветке — не перемещайте коммиты, от которых зависит ещё кто-то.
Откат коммитов — revert и reset
Похожие дебаты по поводу того, что лучше использовать, возникают, когда вы хотите откатить коммит. Команда git revert создаёт новый коммит, отменяющий изменения, но сохраняющий историю, в то время как git reset перемещает указатель HEAD, предоставляя более чистую историю (словно бы этого коммита никогда и не было). Важно отметить, что это также означает, что вы больше не сможете вернуться обратно к этим изменениям, например, если вы всё-таки решите, что отмена коммита была лишней. Чище — не значит лучше!
Продвинутое использование
На этом основное введение в Git заканчивается, и начинается более глубокое изучение.
Интерактивная подготовка
Правка истории
Вы можете поменять порядок коммитов, изменив порядок, в котором они перечислены.
Изменение сообщения/разбивка коммитов
Перезапись нескольких коммитов
Объединение нескольких коммитов
Если коммиты незначительные и небольшие, это может засорить историю проекта. В связи с этим можно объединить несколько коммитов в один большой. Используйте команду pick для выбора первого коммита и squash для последующих.
Перенос отдельного коммита
Обратите внимание, что таким образом создаётся новый коммит, который только повторяет diff выбранного коммита (то есть разницу между этим коммитом и предыдущим), но не его состояние.
Основы Git
Git очень удобная система контроля версий, которая сейчас используется практические повсеместно. Она нужна для того, чтобы команды могли кооперироваться в создании программного продукта и совмещать код написанный разными людьми в одном репозитории.
Когда я учил Git мне говорили, что в работе мне понадобятся всего 3 команды:
Правда, по сути мне немного слукавили, нужен был ещё как минимум:
Однако, на этом все мои теоретические знания по Git заканчивались и достаточно долгое время я пользовался только этими командами, покуда в один момент не начал работать над веб-приложениями, над которыми со мной работали ещё несколько человек.
Там мне объяснили какие команды также нужны в разработке, зачем они используются и как часто они используются. Сегодня я решил поделиться этими командами с вами.
Основная терминология
Работа с Git
Прежде всего нам понадобятся команды для работы с файлами. Знать add конечно хорошо, но нужно иногда и удалять что-то из кэшируемых файлов или изменять поведение Git для определенных файлов. Сегодня я разберу некоторые команды, которые позволят вам манипулировать с файлами, ветками, коммитами в Git.
init
Данная команда инициализирует систему контроля версий. Для того чтобы создать новый репозиторий достаточно просто ввести:
clone
Данная команда нужна для того, чтобы клонировать репозиторий из облака. Можно клонировать репозитории из Github, Gitlab, BitBucket и других сервисов. Для того чтобы склонировать репозиторий нужно ввести:
Данная команда понадобится вам, когда вам нужно добавить файл для кэширования. Давайте разберёмся как это работает:
Вы изменяете файлы, можете изменять достаточно много файлов, задачи изменения которых вообще никак не связаны
Вы решаете «закоммитить» ваши файлы (сделать сохранение версии, для того чтобы Git запомнил все ваши изменения в файлах и как-то назвал их, для этого есть отдельная команда git commit )
Вы также можете добавить файлы, которые ранее не отслеживались, для того чтобы Git занёс их в свою систему хранения версий и вы могли откатываться на какую-то из версий файла
Проделав данный алгоритм, состоящий из двух команд вы занесёте все файлы из вашего проекта в систему контроля версий Git.
Но, что если вам не хочется вносить все файлы? Тогда вы может использовать следующий синтаксис:
Также мы можем сделать так, чтобы Git искал некоторые названия в дочерних директориях и игнорировал их:
Данная команда поможет, когда нам нужно избавиться от файла, она подобно команде rm удаляет файл из файловой системы и кэша Git, позволяя нам быстро избавиться от файла.
Данный пример удалит файл file.txt из кэша и файловой системы.
Но, что если мы добавили файл, который нам более не нужен в кэше, но нужен в файловой системе? Тогда мы можем воспользоваться следующей командой:
Данная команда удалит файл из «кэша», но что это значит? Допустим, что мы «закоммитили» (сохранили версию, об этом поговорим вот уже совсем скоро) наш файл, а теперь хотим, чтобы Git считал что мы его удалили, а сами просто оставили его на диске. Для этого и нужна команда выше. Она просто говорит Git: «Слушай, а давай ты просто удалишь этот файл из кэша и не будешь его показывать в репозитории, а я оставлю копию у себя на ПК, ок?»
Таким образом мы можем работать с данным файлом и Git не будет знать что именно в нём мы изменяем, а затем просто можем опять добавить его. Файл будет висеть в состоянии «untracked» (не отслеживается) до тех пор, покуда мы его опять не добавим.
commit
Думаю, что стоит поговорить об этом уже сейчас, ибо позже без данной команды уже никуда. Данная команда буквально сохраняет версию, в которой указывается что именно в файлах мы изменили.
Обычно разработчики сохраняют версию программы с помощью данной команды:
В данном случае мы просто скажем, чтобы Git сохранил все изменения, которые мы сделали в файлах, которые отслеживаются. Файлы, которые не отслеживаются просто не попадают в версию, а также их изменения никак нельзя отследить.
Для того чтобы отменить последний коммит (отменить не изменения, а именно просто разкоммитить изменения) и совместить его с текущими изменениями используйте команду:
show
Данная команда нужна для того, чтобы быстро показать что было сделано за предыдущие коммит:
Выведутся изменения следующим образом:
status
До этого момента мы могли только посмотреть что творилось в предыдущем коммите, однако с помощью git log мы можем посмотреть историю наших коммитов:
Если же вы хотите красиво вывести все ваши коммиты в столбик, то используйте данную команду:
В данной команде мы описываем что хотим просматривать коммиты и их названия в одну строку, хотим чтобы коммиты сокращали свой ID, а также чтобы всё это красиво было разбито по списку
diff
С помощью данной команды мы можем посмотреть на изменения между коммитами. Эта комманда является одной из самых мощных в Git, вам стоит обратить на неё внимание:
Так называемые «ID-коммита» можно взять и вышеприведенной git log
Если вы хотите посмотреть историю изменений в файлах в определенном коммите, то используйте следующую команду:
Если вы хотите посмотреть на изменения только тех файлов, которые добавлены для отслеживания, то нужно ввести следующую команду:
branch
В Git есть ветки для разделения версий. Если коммит нужен для того, чтобы сделать snapshot (слепок изменений) файлов, то ветки нужны для того, чтобы эти snapshot’ы разделять. У вас может быть ветка
любое другое название
Для того чтобы перечислить все ветки с помощью Git нужно ввести следующую команду:
Для того чтобы создать новую ветку нужно ввести:
checkout
Checkout используют для того, чтобы переходить между ветками. Для того чтобы перейти на другую ветку достаточно просто написать:
Для того чтобы создать ветку и сразу же перейти на неё достаточно ввести:
merge
Соединение веток не являются сложной темой. Для того чтобы слить текущую ветку с другой нужно ввести:
push
В завершение
Здесь мы чуть более глубже познакомились с основами Git, поняли как работать с ветками, как их мерджить, как коммитить файлы, смотреть изменения, а также как показывать последние коммиты.
Если вы хотите больше узнать о веб-разработке, а также о линуксе, то милости прошу в мой блог на телеграм.
Надеюсь данная статья помогла вам чуть лучше узнать Git. Хорошего дня и продуктивной недели!
Первый коммит в Github
Руководство по созданию первого коммита в свой репозиторий на Github
В этом мануале представлены основные сведения об инструментах контроля версий программного обеспечения и рассмотрен алгоритм создания локального репозитория, связанного с удалённым.
Основы
GitHub — онлайн-хостинг репозиториев, обладающий всеми функциями системы контроля версий и функциональностью управления (в него входит всё то, что поддерживает Git). Вместе с Git он даёт разработчикам возможность сохранять их код онлайн, а затем взаимодействовать с другими разработчиками в разных проектах.
Git — это инструмент, позволяющий реализовать распределённую систему контроля версий.
GitHub — это сервис для проектов, использующих Git.
Создать коммит (commit) значит зафиксировать изменения любых файлов, входящих в репозиторий.
Репозиторий — каталог файловой системы, в котором могут находится: файлы журналов конфигураций и операций, выполняемых над репозиторием, а также сами контролируемые файлы.
Репозиторий бывает:
Для первого коммита на Github необходимо установить Git, создать локальный репозиторий, добавить в него файлы, сделать коммит, подключиться к удалённому репозиторию и отправить в него изменения.
Установка Git
Для Linux:
1. Откройте терминал и перейдите в желаемую директорию для установки.
2. Введите: sudo apt-get install git
Для macOS:
1. Воспользуемся homebrew
2. Вводим в терминале: brew install git
Для Windows, (для macOS и Linux — альтернатива):
1. Перейдите по ссылке: http://git-scm.com/downloads
2. Выберите нужный пакет и следуйте дальнейшим инструкциям.
Далее работа с Git будет выполняться в терминале Bash, который станет доступен на любой ОС после установки Git. Так вы будете лучше понимать устройство работы с системами контроля версий и возможности графического клиента ограничены по сравнению с консольным.
Создание и настройка локального репозитория
Пусть наш проект имеет путь в файловой системе Users/Public/Project. Перед созданием локального репозитория желательно удалить все ненужные, временные файлы в папке проекта.
2. Настроим имя пользователя и адрес электронной почты:
(где Name – логин пользователя, email@mail.ru — почта)
Теперь каждое наше действие будет отмечено именем и почтой, это вносит порядок в историю изменений.
tree – команда для просмотра древовидной структуры файловой системы, в которой мы находимся.
find – удаление файлов со специфичным суффиксом.
3. Переходим в папку с проектом Users/Public/Project:
4. Создадим локальный репозиторий в папке с проектом:
Командная строка должна вернуть что-то вроде:
Добавление файлов в локальный репозиторий
1. Теперь создадим любой файл в нашей директории, например, first.txt
2. Добавим его в систему управления версиями:
3. Если нужно добавить все файлы в директории, то используем:
4. Проверить текущее состояние:
Можно отменить добавление файла командой:
Создание версии проекта
После добавления нужного файла в staging area (область подготовленных файлов) можно создать версию проекта.
Ключ –m означает создание пользователем описания этого коммита.
Для удаления всеx файлов в папке, не относящихся к проекту, и не сохраненных в репозитории, можно воспользоваться командой:
Создание репозитория на Github
Все действия до этого раздела производились над локальным репозиторием, который находится у вас на компьютере. Если мы хотим сохранить проект в Интернете, и предоставить к нему доступ, то создадим репозиторий на Github.
1. Регистрируемся на сайте: github.com под именем nikname (может быть любым другим).
2. Нажимаем кнопочку «+» и вводим название репозитория.
3. Выбираем тип Public (Private доступен только в платной версии).
4. Нажимаем Create.
В результате создан репозиторий в Github (на экране видим инструкцию, по соедининению локального репозитория со вновь созданным).
5. Добавляем удаленный репозиторий (по протоколу SSH) под именем origin (желательно использовать его, но можно любое другое, главное – не master – оно используется в момент релиза версии).
Результат можно увидеть с помощью команды:
Если все правильно сделано, то увидим:
Для отмены регистрации удаленного репозитария, введите:
Этой командой вносятся все изменения, которые были сделаны в локальном репозитории на Github:
-u ключ установления связи между удаленным репозиторием github и веткой master. Все дальнейшие изменения переносятся на удаленный репозиторий следующей командой: git push