Лёгкое введение в Git
от Ксакеп
> Люди делятся на два типа. На тех кто не делает бэкапы, и тех кто уже делает.
В жизни любого человека наступает момент, когда результаты долгой работы, будь то исходный код программы, бакалаврская или просто сборник рецептов, внезапно теряются. Это может произойти по любым причинам, например, если ваш компьютер будет атакован крипто-локером или истечёт срок службы работы жесткого диска.
Обычно "продвинутые" пользователи поступают следующим образом: с некоторой частотой архивируют данные, именуют их датой бэкапа, и отправляют на какое-нибудь облачное хранилище. Этот процесс можно даже автоматизировать, но сейчас я покажу, почему это неудобно и как можно сделать лучше.
Допустим, вы разрабатываете серьёзный коммерческий продукт на протяжении достаточно длительного периода времени, и внезапно ваш кот Иннокентий признаётся, что около месяца назад сделал серьезные правки по всему проекту так, что конфиденциальные данные миллионов владельцев банковских счетов теперь в его лапах. Итак, вот уже четыре дня подряд вы пытаетесь отыскать в ваших бесчисленных бекапах версию программы без правок кота, когда внезапно к вам в дом врывается наряд полиции и забирает вас под стражу.
Как можно было этого избежать? К счастью, умные программисты предусмотрели подобное развитие событий, и придумали очень крутую штуку, которая называется системой контроля версий (VSC). Её цель — облегчить работу с изменяющимися файлами, например, хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение. В этой статье мы слегка рассмотрим самую популярную систему Git.
Как это работает
Процесс написания программы можно разбить на мелкие события: вы написали новую функцию или класс, исправили серьёзный баг, добавили новый функционал, подготовили тесты, и т.д. Поэтому в git принято фискировать такие события и делать своеобразный бэкап, который мы будем называть коммитом (commit). Очевидно, серия таких событий или коммитов составляют историю написания программы.
Место, где хранятся коммиты и прочая служебная информация называется репозиторием. Итак, у каждого разработчика на своей машине есть свой локальный репозиторий, где он спокойно быдлокодит работает над проектом. При желании поделиться результатом с другими разработчиками, он отправляет копию своего локального репозитория на главный внешний репозиторий. Это обеспечивает сохранность данных, даже при условии, если большую часть разработчиков собьёт автобус.
Как уже было сказано ранее, используя git, вы можете откатиться к любому коммиту (любой версии проекта) в репозитории, если допустили ошибку; либо определить, кто именно сделал коммит с ошибкой и соответственно наказать этого негодяя; можно также увидеть, какие изменения были сделаны в последние три месяца в определённом файле. Но почему всё это становится возможным?
На самом деле git не хранит полные бэкапы файлов на каждое из состояний, которые мы фиксируем. Это так, потому что гораздо удобнее оказывается хранить изменения в файлах. Если вы удаляете какую-нибудь функцию и добавляете новый класс — то git записывает, что строки 5-12 были удалены, и появился новый код в строках 30-50. Таким образом, серия коммитов — это последовательность изменений файлов в репозитории, а откат к более ранней версии — это всего лишь последовательное применение изменений.
Более того, каждый коммит хранит информацию о том, кем и когда этот коммит был совершен, а также уникальное имя, состоящее из букв и цифр.
Первые шаги
После небольшого теоретического ознакомления, было бы очень неплохо попробовать этот инструмент лично, поэтому приглашаю вас на страницу загрузки. Если вы пользователь Windows, то на определённом шаге инсталлятор спросит какой тип запуска git вы предпочитаете. Выбирайте Git bash only , тогда будет произведена установка MinGW — порт терминала Bash на Windows. Выглядит так:
Сразу при первом запуске надо настроить git: указать имя и почту, которыми будут подписываться все ваши коммиты (между прочим, необязательно писать правду). Замечание: знак доллара писать не нужно, это символ Bash, обозначающий, что консоль готова обрабатывать команды.
Давайте создадим каталог "myrepo", где будет храниться репозиторий.
После ввода git init в жёлтой строке должно появиться (master) . Можете воспринимать это как будто вы стали мастером (профи).
Создадим новый файл, например, webpage.html , с некоторым простым содержимым. И вызовем git status .
Git оповещает, что появились так называемые untracked файлы, то есть файлы, за которыми репозиторий не следит и которые никогда не будут закоммичены, пока мы явно не укажем обратное. Чтобы доказать git'у, что это достойный файл и его нужно будет закоммитить, напишем следующее:
Итак, мы явно попросили git добавить файл в индекс (то есть начать следить за ним), а после вызвали git status , чтобы убедиться, что файл действительно отслеживается. Теперь можно сделать коммит, указав некоторое сообщение с помощью флага -m (message).
Таким образом, цикл разработки выглядит следующим образом:
Заключение
Известен случай, когда команда математиков за полгода написала 600-страничную книгу, используя git — это успех! Поэтому не бойтесь и начинайте им пользоваться, особенно если вы занимаетесь разработкой ПО. Лучше всего работать и осваивать команды в консольном интерфейсе, хотя есть и GUI- варианты, например, SourceTree или TortoiseGit. Удачи!
В жизни любого человека наступает момент, когда результаты долгой работы, будь то исходный код программы, бакалаврская или просто сборник рецептов, внезапно теряются. Это может произойти по любым причинам, например, если ваш компьютер будет атакован крипто-локером или истечёт срок службы работы жесткого диска.
Обычно "продвинутые" пользователи поступают следующим образом: с некоторой частотой архивируют данные, именуют их датой бэкапа, и отправляют на какое-нибудь облачное хранилище. Этот процесс можно даже автоматизировать, но сейчас я покажу, почему это неудобно и как можно сделать лучше.
Допустим, вы разрабатываете серьёзный коммерческий продукт на протяжении достаточно длительного периода времени, и внезапно ваш кот Иннокентий признаётся, что около месяца назад сделал серьезные правки по всему проекту так, что конфиденциальные данные миллионов владельцев банковских счетов теперь в его лапах. Итак, вот уже четыре дня подряд вы пытаетесь отыскать в ваших бесчисленных бекапах версию программы без правок кота, когда внезапно к вам в дом врывается наряд полиции и забирает вас под стражу.
Как можно было этого избежать? К счастью, умные программисты предусмотрели подобное развитие событий, и придумали очень крутую штуку, которая называется системой контроля версий (VSC). Её цель — облегчить работу с изменяющимися файлами, например, хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение. В этой статье мы слегка рассмотрим самую популярную систему Git.
Как это работает
Процесс написания программы можно разбить на мелкие события: вы написали новую функцию или класс, исправили серьёзный баг, добавили новый функционал, подготовили тесты, и т.д. Поэтому в git принято фискировать такие события и делать своеобразный бэкап, который мы будем называть коммитом (commit). Очевидно, серия таких событий или коммитов составляют историю написания программы.
Место, где хранятся коммиты и прочая служебная информация называется репозиторием. Итак, у каждого разработчика на своей машине есть свой локальный репозиторий, где он спокойно быдлокодит работает над проектом. При желании поделиться результатом с другими разработчиками, он отправляет копию своего локального репозитория на главный внешний репозиторий. Это обеспечивает сохранность данных, даже при условии, если большую часть разработчиков собьёт автобус.
Как уже было сказано ранее, используя git, вы можете откатиться к любому коммиту (любой версии проекта) в репозитории, если допустили ошибку; либо определить, кто именно сделал коммит с ошибкой и соответственно наказать этого негодяя; можно также увидеть, какие изменения были сделаны в последние три месяца в определённом файле. Но почему всё это становится возможным?
На самом деле git не хранит полные бэкапы файлов на каждое из состояний, которые мы фиксируем. Это так, потому что гораздо удобнее оказывается хранить изменения в файлах. Если вы удаляете какую-нибудь функцию и добавляете новый класс — то git записывает, что строки 5-12 были удалены, и появился новый код в строках 30-50. Таким образом, серия коммитов — это последовательность изменений файлов в репозитории, а откат к более ранней версии — это всего лишь последовательное применение изменений.
Более того, каждый коммит хранит информацию о том, кем и когда этот коммит был совершен, а также уникальное имя, состоящее из букв и цифр.
Первые шаги
После небольшого теоретического ознакомления, было бы очень неплохо попробовать этот инструмент лично, поэтому приглашаю вас на страницу загрузки. Если вы пользователь Windows, то на определённом шаге инсталлятор спросит какой тип запуска git вы предпочитаете. Выбирайте Git bash only , тогда будет произведена установка MinGW — порт терминала Bash на Windows. Выглядит так:
Сразу при первом запуске надо настроить git: указать имя и почту, которыми будут подписываться все ваши коммиты (между прочим, необязательно писать правду). Замечание: знак доллара писать не нужно, это символ Bash, обозначающий, что консоль готова обрабатывать команды.
- $ git config --global user.name "cat"
Давайте создадим каталог "myrepo", где будет храниться репозиторий.
- $ mkdir myrepo # make directory with name "myrepo"
- $ cd myrepo # change directory to "myrepo"
- $ git init # initialize new empty repository
- $ git status # status of the repository
После ввода git init в жёлтой строке должно появиться (master) . Можете воспринимать это как будто вы стали мастером (профи).
Создадим новый файл, например, webpage.html , с некоторым простым содержимым. И вызовем git status .
- # create file "webpage.html" with content "hello"
- $ echo "hello" > webpage.html
- $ git status
- > Untracked files:
- > webpage.html
Git оповещает, что появились так называемые untracked файлы, то есть файлы, за которыми репозиторий не следит и которые никогда не будут закоммичены, пока мы явно не укажем обратное. Чтобы доказать git'у, что это достойный файл и его нужно будет закоммитить, напишем следующее:
- $ git add webpage.html # add this file to index, to tracked files
- $ git status
- > Changes to be committed:
- > new file: webpage.html
Итак, мы явно попросили git добавить файл в индекс (то есть начать следить за ним), а после вызвали git status , чтобы убедиться, что файл действительно отслеживается. Теперь можно сделать коммит, указав некоторое сообщение с помощью флага -m (message).
- $ git commit -m "webpage was created"
- $ git status
- > nothing to commit, working directody clean
Таким образом, цикл разработки выглядит следующим образом:
Заключение
Известен случай, когда команда математиков за полгода написала 600-страничную книгу, используя git — это успех! Поэтому не бойтесь и начинайте им пользоваться, особенно если вы занимаетесь разработкой ПО. Лучше всего работать и осваивать команды в консольном интерфейсе, хотя есть и GUI- варианты, например, SourceTree или TortoiseGit. Удачи!
