Система контроля версий для windows

Время на прочтение8 мин

Количество просмотров26K

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

Естественно, поиски были начаты с изучения Хабра — и привели к неожиданному результату. Несмотря на то, что системы контроля версий появились ещё в 1986 году, большинство туториалов по работе с современными системами контроля версий оказались неполными и сильно завязанными на работу с командной строкой.

Мы ничего не имеем против командной строки в целом, но в нашей небольшой команде разработчиков (4 человека) фанатов работы с командной строкой нет :).

Почему мы считаем, что работа с командной строкой неэффективна?

1. Трата времени на ввод данных. Набивать команды намного дольше, чем кликать мышкой.
2. Трата времени на обучение. Изучение нового синтаксиса в эпоху понятных интерфейсов однозначно дольше, чем обучение графическому интерфейсу.
3. Вероятность ошибки. Ошибиться при вводе данных через командную строку легче (человеческий фактор никто не отменял).
4. Нарушение принципов автоматизации. Возможно, это самый главный пункт. Компьютер создан для ускорения работы и замене человека при выполнении рутинных операций. В случае с командной строкой мы всегда работаем вручную, по сути, приходится каждый раз писать один и тот же программный код (пусть и примитивный).

К сожалению, нам не удалось найти полноценного русскоязычного мануала по работе с современными системами контроля версий. Собрав информацию из разных статей и англоязычных видео на YouTube, мы решили сделать своё собственное руководство, которое:

1. Будет пошаговой инструкций (по ней же будут работать наши программисты).
2. Будет работать от начала и до конца (то есть по ней вы получите небольшой, но законченный результат — работающую распределенную систему контроля версий).
3. Будет работать с использованием только графических интерфейсов (причины см. выше).

Вступление

Вопреки ожиданиям матерых сисадминов и прочих любителей и фанатов работы с командной строкой, в данной статье не будет никаких команд, выполняемых с помощью командной строки. Вся статья написана языком понятным даже тем, кто только недавно начал программировать, но уже задумался о внедрении VCS (системы контроля версий). Каждый шаг настройки VCS разжеван до мелочей с приведением принскринов и дополнительных пояснений.

Если вы не любитель мануалов «Для чайников», то можете не читать данную статью и пойти своим путем в решении задачи подъема VCS.

Используемые программы и сервисы

Для развертывания VCS (системы контроля версий) мы будем использовать следующие программы и сервисы:

• Mercurial — кроссплатформенная распределенная система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода.
• TortoiseHg — графический фронтенд для системы контроля версий Mercurial.
• Bitbucket — веб-сервис для хостинга проектов и их совместной разработки, основанный на системе контроля версий Mercurial и Git.

Развертывание система контроля версий – пошаговая инструкция

1. Скачиваем и устанавливаем к себе на компьютер TortoiseHg с официального сайта: http://tortoisehg.bitbucket.org/

Картинка с сайта: habr.com

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

В данной инструкции все шаги настройки и работы с системой контроля версий будут производиться с использованием TortoiseHg версии: 2.10.1 for Windows 64-bit with Mercurial 2.8.1.

2. Регистрируемся в веб-сервисе Bitbucket: https://bitbucket.org/
Весь процесс регистрации сводится к заполнению контактных данных (Username, Email и т.д.) и подтверждения указанного при регистрации email-адреса нажатием на кнопку «Confirm this email address» в полученном после регистрации письме.

Картинка с сайта: habr.com

Регистрироваться в сервисе Bitbucket потребуется также всем участникам вашей команды разработчиков. К великому счастью стартапов в данном сервисе есть бесплатный аккаунт, который позволяет создавать приватные репозитории с 5-ю пользователями. Также есть возможность увеличения максимального числа членов команды, участвующей в разработке на бесплатном тарифе до 8 человек.

С полным списком тарифов вы можете ознакомиться, пройдя по ссылке: https://bitbucket.org/plans

3. Зайдя в ваш аккаунт в сервисе Bitbucket, вы можете сразу изменить язык интерфейса вашего аккаунта на русский.

Для этого в верхнем правом углу главного меню из выпадающего списка выберите раздел «Manage account» и на открывшейся странице выберите из выпадающего списка «Language» нужный вам язык интерфейса

Картинка с сайта: habr.com

4. Для создание репозитория для вашего проекта вам необходимо перейдите на главную страницу вашего аккаунта (https://bitbucket.org/dashboard/overview) и нажмите на кнопку «Создайте ваш первый репозиторий»

Картинка с сайта: habr.com

5. На странице создания нового репозитория укажите следующие настройки:

— Имя – Укажите имя вашего нового репозитория. Данное имя используется для построения ссылки доступа к вашему репозиторию.
Важно! Лучше указывать имя латинскими буквами, иначе ссылка на репозитрий будет заканчиваться дефисами и иметь сложный к пониманию вид: httрs://вашлогин@bitbucket.org/вашлогин/———

— Описание – Укажите краткое описание вашего репозитория (поле не обязательное)
— Уровень доступа – Поставьте галочку, если вы хотите, чтобы доступ к вашему репозиторию имели только члены вашей команды разработчиков (приватный репозиторий).
— Создание форков – Поставьте «Разрешить только приватные форки»
— Тип репозитория – Выберите «Mercurial»
— Управление проектом – Поставьте галочки «Трекер задач» и «Вики»
— Язык – Выберите язык разработки, на котором написан ваш проект. В моем случае это PHP.

По завершению указания всех настроек страница будет выгладить приблизительно так:

Картинка с сайта: habr.com

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

6. После создания нового репозитория вы попадете на страницу «Начало работы»:

Картинка с сайта: habr.com

Где, нажав на ссылку «Я начинаю с полного нуля», сможете получить ссылку для подключения к вашему репозиторию с помощью TortoiseHg.

Ссылка будет иметь вид: httрs://вашлогин@bitbucket.org/вашлогин/имярепозитория

7. У себя на компьютере создаете пустую папку, в которой будут в дальнейшем храниться файлы вашего проекта, подключенные к системе контроля версий Mercurial.

Важно! Папка должна быть пустой. Мне, например, для подключения папки с уже существующим проектом (кучей программного кода) пришлось временно перенести все файлы в другой каталог (сделать резервную копию — backup). Позже мы вернем все файлы на место, а пока нужно полностью очистить папку для подключения.

Далее нажимаем на пустой папке, предназначенной для хранения файлов проекта, подключенных к системе контроля версий Mercurial, правой кнопкой мыши и из выпадающего меню выбираем пункт «TortoiseHg->Clone…»

Картинка с сайта: habr.com

8. В открывшемся окне вам необходимо указать в поле «Источник» ссылку для подключения к созданному вами репозиторию из п. 6

Картинка с сайта: habr.com

И нажать кнопку «Клонировать».

9. Система запросит у вас пароль от вашего аккаунта в сервисе Bitbucket, укажите его.

Картинка с сайта: habr.com

10. Если все было сделано без отклонений от данной инструкции, то в папке появится новый каталог «.hg» со служебными файлами созданного репозитория.

11. Теперь можно смело возвращать файлы (программный код) вашего проекта в папку, предназначенную для хранения файлов проекта, подключенных к системе контроля версий Mercurial

Важно! Служебный каталог «.hg» не трогайте. Он нужен для работы VCS.

12. Снова нажимаем правой кнопкой мыши на нашей папке проекта и из выпадающего меню выбираем пункт «Hg Commit…»

Картинка с сайта: habr.com

13. Вы увидите диалоговое окно, предназначенное для фиксации всех сделанных изменений, произведенных над вашим проектом (в данном случае мы добавили в изначально пустую папку проекта наши программные коды).

Вам необходимо выделить все измененные (добавленные) файлы, указать комментарий (например, Версия 1.00) к изменению и нажать кнопку «Фиксировать».

Система попросит подтвердить добавление, жмите «Добавить».

Картинка с сайта: habr.com

14. Если все было сделано правильно, то система зафиксирует произведенные изменения, и вы увидите приблизительно такое окно:

Картинка с сайта: habr.com

Собственно, в дальнейшем, когда будете вести разработку, после завершения небольшого куска кода, вы будете выполнять действие из п. 12 (нажимать «Hg Commit…») для фиксации проделанного изменения в системе контроля версия. Это даст вам возможность в любой момент времени откатить систему до предыдущей фиксации.

Учитывая вышесказанное, на практике следует писать более развернутый, чем «Версия 1.00», комментарий к каждой из фиксаций.

15. Далее нажимаем правой кнопкой мыши на папке проекта и из выпадающего меню выбираем пункт «Hg Workbench…»

Картинка с сайта: habr.com

16. В открывшемся окне вы можете видеть всю историю сохраненных (зафиксированных) изменений в коде, можете откатить к нужной фиксации, а также отправить изменения в созданный вами ранее репозиторий.

Для этого в панели управления выберите кнопку «Протолкнуть входящие изменения в».

Картинка с сайта: habr.com

После этого вам будут показаны диалоговые окна с просьбой подтвердить «проталкивание» и просьбой указать пароль от вашего аккаунта в Bitbucket. Соглашайтесь и указывайте пароль.

Система начнет копирование файлов в ваш репозиторий на сервере Bitbucket. Не спешите и дождитесь завершения процесса.

17. Теперь копия файлов вашего проекта храниться в вашем репозитории на серверах Bitbucket. В вашем аккаунте Bitbucket вы можете видеть всю историю работы с вашим проектом.

Картинка с сайта: habr.com

Промежуточные итоги подключения системы контроля версий (VCS)

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

Процесс подключения вашего второго компьютера заключается в копировании файлов из репозитория на второй компьютер. Вам нужно пройти шаги 1 – Установка TortoiseHg и 7 – Импорт файлов репозитория, для копирования файлов на второй, третий и следующие ваши рабочие компьютеры.

Подключение сотрудников к вашему репозиторию.

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

Поэтому давайте сейчас подключим к нашему проекту еще одного программиста (пригласим участника) и настроим ему рабочее место.

Подключение сотрудника к нашему репозиторию

18. Все сотрудники, которые будут иметь доступ к вашему репозиторию, должны быть зарегистрированы на сервисе Bitbucket. А также у них на компьютерах должен быть установлен TortoiseHg.

Как зарегистрироваться на сервисе и установить TortoiseHg, я рассказывал чуть ранее в данной инструкции. Поэтому данный процесс не должен вызвать у вас и ваших коллег никаких трудностей.

19. Зайдите в ваш аккаунт на сервисе Bitbucket:

Картинка с сайта: habr.com

Нажмите на кнопку «Отправить приглашение», расположенную в разделе «Пригласить участника на этот репозиторий».

20. Система выведет вам диалоговое окно с просьбой указать электронный адрес пользователя, которому вы хотите дать доступ к репозиторию. Помимо этого, вам понадобится указать права доступа («чтение» или «запись»). Т.к. в данной инструкции мы показываем, как подключить к репозиторию еще одного разработчика, то укажите «запись».

Картинка с сайта: habr.com

После того, как ввели email сотрудника и указали права доступа, жмите кнопку «Share».

21. Приглашенный участник получит на свой email письмо со ссылкой на приглашение. Ему будет необходимо пройти по данной ссылке и принять приглашение на доступ к вашему репозиторию.

Картинка с сайта: habr.com

Еще раз повторю, все участники вашего репозитория должны быть зарегистрированы в сервисе Bitbucket.

22. После того, как приглашение принято, новый участник будет видеть у себя в аккаунте данный репозиторий и свою ссылку на доступ к нему с помощью TortoiseHg.

Картинка с сайта: habr.com

23. Дальше вашему сотруднику необходимо выполнить 7 пункт данной инструкции для получения файлов проекта к себе на компьютер.

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

Картинка с сайта: habr.com

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

Данный подход мы применили для разработки проекта: АвтоОфис – платформа для интернет бизнеса

Если у вас после прочтения статьи появились вопросы ко мне или уточнения и дополнения инструкций, то пишите в комментариях. Буду очень благодарен, если усилите статью своим пониманием VCS.

P.S.: В следующей статье постараюсь доступным языком расписать, что такое «Ветки», «Метки» и «Форки» и как с ними работать.

Установка и настройка систем контроля версий

Введение в системы контроля версий

Системы контроля версий (VCS) являются неотъемлемой частью современного процесса разработки программного обеспечения. Они позволяют отслеживать изменения в коде, работать в команде и управлять различными версиями проекта. Самой популярной VCS на сегодняшний день является Git. В этой статье мы рассмотрим, как установить и настроить Git, а также основные операции, которые помогут вам начать работу с этой системой.

Git предоставляет мощные инструменты для управления версиями кода, что делает его незаменимым для разработчиков. С его помощью можно легко отслеживать изменения, откатываться к предыдущим версиям, работать над разными ветками проекта и сливать изменения. Это особенно важно в командной работе, где каждый разработчик может вносить свои изменения, не боясь повредить общий код.

Картинка с сайта: sky.pro

Установка Git на различных операционных системах

Установка Git на Windows

1. Перейдите на официальный сайт Git: git-scm.com.
2. Скачайте установочный файл для Windows.
3. Запустите установочный файл и следуйте инструкциям мастера установки.
4. Во время установки выберите параметры по умолчанию, если не уверены, что вам нужно изменить.

После завершения установки Git, вы можете проверить, что все прошло успешно, открыв командную строку и введя команду:

Эта команда выведет установленную версию Git, что подтвердит успешную установку.

Установка Git на macOS

1. Откройте терминал.
2. Введите команду:

   sh
brew install git

3. Если у вас не установлен Homebrew, сначала установите его, следуя инструкциям на официальном сайте Homebrew.

Homebrew является удобным менеджером пакетов для macOS, который упрощает установку и управление программным обеспечением. После установки Git с помощью Homebrew, вы также можете проверить версию Git, введя команду:

Установка Git на Linux

Для различных дистрибутивов Linux команды могут немного отличаться:

Ubuntu/Debian

Fedora

Arch Linux

После установки Git на любой из этих дистрибутивов, вы можете проверить версию Git с помощью команды:

Настройка Git: базовые команды и конфигурации

После установки Git необходимо выполнить несколько базовых настроек.

Настройка имени пользователя и электронной почты

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

Проверка настроек

Для проверки текущих настроек используйте команду:

Эта команда выведет все текущие настройки Git, включая имя пользователя и электронную почту. Это полезно для проверки, что все настройки были применены правильно.

Настройка редактора по умолчанию

Вы можете настроить редактор, который будет использоваться для написания сообщений коммитов. По умолчанию Git может использовать системный редактор, но вы можете изменить это на любой удобный вам редактор.

Вы можете заменить «nano» на любой другой редактор, который вам нравится, например, «vim» или «code» (Visual Studio Code).

Создание и управление репозиториями

Создание нового репозитория

Для создания нового репозитория выполните следующие шаги:

1. Перейдите в директорию вашего проекта:

   sh
cd /путь/к/проекту

2. Инициализируйте новый репозиторий:

   sh
git init

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

Клонирование существующего репозитория

Если вы хотите склонировать существующий репозиторий, используйте команду:

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

Добавление файлов в репозиторий

Для добавления файлов в репозиторий используйте команду:

Вы также можете добавить все файлы в текущей директории с помощью команды:

Создание коммитов

После добавления файлов необходимо создать коммит:

Сообщение коммита должно быть информативным и описывать внесенные изменения. Это поможет вам и вашим коллегам понимать, что было изменено в каждом коммите.

Основные операции с ветками и слияниями

Создание новой ветки

Для создания новой ветки используйте команду:

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

Переключение между ветками

Для переключения на другую ветку используйте команду:

Эта команда переключит вас на указанную ветку, позволяя вам работать над ней. Вы можете проверить, на какой ветке вы находитесь, с помощью команды:

Слияние веток

Для слияния изменений из одной ветки в другую выполните следующие шаги:

1. Переключитесь на ветку, в которую хотите слить изменения:

   sh
git checkout основная_ветка

2. Выполните слияние:

   sh
git merge имя_ветки

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

Удаление ветки

Для удаления ветки используйте команду:

Удаление веток помогает поддерживать чистоту в вашем репозитории, удаляя ненужные или устаревшие ветки.

Заключение

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

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

Читайте также

Памятуя о статье Коротко о системе контроля версий и подозревая, что самому масса вещей еще понадобится, за две недели нарисовал этот текст. Сначала думал сделать одну большую статью, но объем такой статьи получился запредельным (больше 5 метров со всеми картинками), поэтому разбил на несколько кусочков.
Получился небольшой цикл из 4 статей (включая эту), посвященный работе с 3 клиентами cvs: TortoiseSVN, SourceTree и GitExtensions. Разбирался с ними по русскому принципу — т.е. инструкцию начинал читать только когда понимал что «все, звездец, сломал». Так что особо строго не судите

Это модное и не очень понятное слово «дисклайм»
Ну как бы предупреждение по принципу «кто не спрятался, я не виноват», «я не несу никакой ответственности бла-бла-бла», «это не мануал, а просто рассказ о моих поисках» и т.д.
Это всего лишь рассказ о собственных мучениях при выборе системы контроля версий и небольшая попытка свести все воедино. Ну и плюс, как обычно, шпаргалка для себя любимого – чтобы не забыть, что, откуда, как и почему. Если не испугал – добро пожаловать
Чуть-чуть о системах контроля версий
В свое время остро встал вопрос с хранением исходных кодов, компилированных вариантов (chm, в частности, под понятие компилированных подошел как нельзя более кстати) файлов и, что самое главное, истории их изменения. Крайне желательно иметь историю с комментариями – кто чего сделал и почему.
Такие системы есть, называются Control Version System (сокращают как CVS или VCS — где как), или системы контроля версий. Все хорошо, но надо выбрать наиболее удобную (для конечного пользователя) и гибкую (это уже для поисков «кто чего натворил»). Прежде чем приступать к экспериментам, дадим некоторые вводные условия:

1. Клиентская программа (или клиент) работает под Windows. Без вариантов. Должна работать и под 32, и под 64 бита. Бесплатна и эта бесплатность – официальная.
2. Есть сетевой диск с большим количеством информации на нем. Отслеживать изменения надо только для некоторых папок / каталогов.
3. Вся работа выполняется в условиях недоступности интернета (но софт скачать можно).

В принципе, этого достаточно. Примем также идею, что есть некое центральное хранилище (т.н. «репозиторий»), в котором собственно и хранятся все данные (возможно, в каком-то не очень доступном виде). Есть «рабочие» копии, внутри которых хранятся файлы уже в привычном для человека виде. При этом «рабочей» копией является и сам сетевой диск. Клиентская программа должна позволять быстро и просто как вносить изменения в центральный репозиторий, так и восстанавливать их оттуда.
Вроде ничего не забыл
Естественно, что обязательно должен предоставляться вариант «посмотреть, что и где изменилось». Естественно, что должен быть вариант разрешения конфликтов, неизбежно возникающих при слиянии с центральным репозиторием.
Это модное и не очень понятное слово «дисклайм»
Все эксперименты провожу над Windows 7 Pro x32, со всеми обновлениями. Никакого стороннего софта на компьютере нет вообще (даже антивирус не установлен). Единственное, что изменил – отключил UAC, поскольку каждый раз говорить, что «да, я знаю, чем это грозит; да, я согласен внести изменения» — утомляет.
Примем, что на локальном компьютере есть каталог c:\git_test, преобразованный в сетевой диск v: командой subst, выполненной в командной строке Windows:

Все, виртуальный диск создан и подключен.

В этот каталог поместим несколько подкаталогов – как тех, которые надо отслеживать, так и «лишних» с точки зрения системы контроля версий. Кроме того, поместим несколько файлов напрямую в «сетевой» диск – тоже для имитации реальной ситуации и для того, чтобы научиться такие файлы игнорировать (целиком или частично). Общий объем перебрасываемой информации – около 2 ГБ, отслеживать надо около 200 МБ (если конкретнее – то каталоги Apps, dotnet, Settings).
Наш центальный репозиторий будем располагать на этом же диске. Для этого создадим там каталог VersionControl. Естественно, что VersionControl надо будет исключать из отслеживаемых каталогов.

Выбор системы контроля версий
Иногда (точнее, не иногда, а почти всегда) ситуация складывается так, что приходится выполнять как бы ветвление разработки. Т.е. выполнять отдельную разработку какого-либо куска кода. При этом внесение этих изменений не должно затрагивать основную массу исходников. Такое понятие тоже есть, называется «Ветка», или «Бранч» (Branch). Ветки потом можно забросить или «слить» с основным потоком разработки.
Т.е. теоретически используемая система должна все это поддерживать и спокойно со всем этим богатством работать. При этом (повторюсь) работать надо из-под Windows и крайне желательно с GUI-интерфейсом. Командную строку я, конечно, уважаю, но не до такой степени, чтобы становиться юниксоидом ради одной утилитки
Не очень продолжительный поиск привел к выбору между SVN и GIT. Вот каждую из них и рассмотрим
Для установки ПО потребуются права локального администратора, для работы они уже не являются необходимыми. Также в процессе установки может потребоваться доступ в интернет. Клиенты нередко обновляются, поэтому крайне желательно время от времени проверять наличие новых версий.

Краткое содержание следующих серий

К сожалению, только сейчас сообразил, что не рассмотрел вариант конфликта версий или веток Ну не получилось у меня пока что наступить на эти грабли Как только столкнусь — расскажу (если не забуду, конечно)

Введение

В этой инструкции покажем, как установить Git на Windows, и поможем выбрать правильные параметры при установке. Затем создадим репозиторий и зафиксируем в нем изменения. Все это поможет вам сделать первые шаги в освоении Git.

Что такое Git и зачем он нужен

Git — это одна из самых популярных систем контроля версий (VCS). Такие системы помогают разработчикам хранить и версионировать исходный код приложений, настройки систем и другие текстовые файлы. И хотя ничего не мешает использовать VCS в других областях, чаще всего они применяются именно в IT.

Каждое состояние файлов в Git можно зафиксировать (сделать коммит), причем это навсегда останется в истории репозитория. Поэтому можно в любой момент посмотреть историю изменений файлов, сравнить различные версии и отменить отдельные изменения.

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

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

Установка Git в Windows

Переходим на официальный сайт Git, в раздел загрузок. Мы увидим несколько вариантов установки: разные разрядности, портативная версия и даже установка из исходников. Мы выберем Standalone-версию, для этого проще всего нажать ссылку Click here to download, она всегда ведет на самую актуальную версию. Запускаем скачанный файл.

Выбор компонентов. Первый экран — выбор компонентов для установки. Если вам нужны дополнительные иконки на рабочем столе, или если вы хотите, чтобы Git ежедневно проверял наличие новой версии, — отметьте соответствующие опции. Остальные параметры лучше оставить по умолчанию.

Картинка с сайта: selectel.ru

Текстовый редактор по умолчанию. Необходимо выбрать редактор, который будет использовать Git — например, когда вы будете писать сообщение для коммита. Это не обязательно должен быть редактор, в котором вы планируете писать исходный код.

По умолчанию в установщике выбран Vim — консольный текстовый редактор, который для многих может показаться сложным в освоении. Если вы не знакомы с Vim и при этом хотите именно консольный редактор — выберите nano. Если у вас уже установлен какой-нибудь текстовый редактор — выбирайте его. Мы для примера будем использовать VSCode.

Картинка с сайта: selectel.ru

Название первой ветки. Тут нужно выбрать, как Git будет называть первую ветку в каждом репозитории. Раньше такая ветка всегда называлась master, но со временем это стало напоминать о временах рабства, и многие проекты и компании стали переименовывать ветки в своих репозиториях. Поэтому разработчики Git добавили эту опцию, чтобы название первой ветки можно было изменить. Мы будем придерживаться старого поведения и оставим название master.

Картинка с сайта: selectel.ru

Способ использования Git. Первая опция сделает Git доступным только из командной строки Git Bash. Это не очень удобно, потому что не позволит пользоваться Git-ом из других оболочек или интегрировать его с редактором кода. Вторая опция самая оптимальная (ее мы и выберем) — она позволяет работать с Git-ом из разных оболочек и интегрировать его с другими приложениями. Третья опция кроме установки Git также «перезапишет» некоторые системные команды Windows аналогами из Unix, и эту опцию нужно выбирать только если вы точно понимаете, что делаете.

Картинка с сайта: selectel.ru

Выбор SSH-клиента. Изначально Git поставлялся со встроенным SSH-клиентом, но недавно появилась опция, где можно использовать внешний клиент. Если у вас уже что-то установлено на компьютере — можете выбрать вторую опцию. Мы же остановимся на первой, так как предварительно ничего не устанавливали.

Картинка с сайта: selectel.ru

Выбор SSL/TLS библиотеки. По умолчанию Git будет использовать свою OpenSSL библиотеку с заранее определенным списком корневых сертификатов. Обычно этого достаточно, но если вам нужно работать со внутренними репозиториям внутри компании, которые используют самоподписанные сертификаты, выберите вторую опцию. Тогда Git будет использовать библиотеку и сертификаты из вашей операционной системы.

Картинка с сайта: selectel.ru

Символы перевода строки. Существует два основных способа формирования конца строки в файлах — CRLF и LF. Первый используется в Windows, второй — в Unix-like системах. Первая опция позволяет извлекать файлы из репозитория в Windows-стиле, при этом отправлять файлы в репозиторий в Unix-стиле. Мы рекомендуем использовать этот вариант, потому что он лучше всего подходит для кросс-платформенной команды, когда над одним кодом могут работать разработчики на разных ОС.

Картинка с сайта: selectel.ru

Эмулятор терминала. Эмулятор, который будет использоваться в командной строке Git Bash. MinTTY — удобный вариант, поэтому он выбран по умолчанию. Встроенный эмулятор CMD не очень удобен, у него есть некоторые ограничения, поэтому выбирайте его, только если делаете это осознанно.

Картинка с сайта: selectel.ru

Стратегия git pull. Первая опция будет пытаться обновить историю коммитов без создания коммитов слияния. Это самый оптимальный и часто используемый вариант, оставим его.

Картинка с сайта: selectel.ru

Credential Manager. Установка этого параметра позволит Git запоминать логины и пароли для подключения к удаленным репозиториям (например, GitHub, GitLab или корпоративное хранилище) и не вводить их постоянно.

Картинка с сайта: selectel.ru

Дополнительные настройки. Кэширование позволит ускорить работу Git, эту опцию рекомендуем оставить. А вот символические ссылки нам не нужны.

Картинка с сайта: selectel.ru

Экспериментальные настройки. Эти опции еще не переведены в стабильную стадию, поэтому их использование рекомендуется, только если вы точно понимаете, что делаете. Мы не будем ничего отмечать.

Картинка с сайта: selectel.ru

Git установлен и готов к работе.

Установка в различные дистрибутивы Linux

Также коротко покажем, как можно установить Git в различные дистрибутивы Linux. Как правило, самостоятельно скачивать ничего не нужно, достаточно воспользоваться встроенным в дистрибутив пакетным менеджером.

Debian

pt-get install git

Ubuntu

add-apt-repository ppa:git-core/ppa # apt update; apt install git

Fedora 21

yum install git

Fedora 22+

dnf install git

Gentoo

emerge --ask --verbose dev-vcs/git

Arch Linux

man -S git

OpenSUSE

ypper install git

Mageia

rpmi git

FreeBSD

pkg install git

OpenBSD

g_add git

RHEL, CentOS, Oracle Linux и др.

Как правило, пакетный установит довольно старую версию Git, поэтому рекомендуется собирать Git из исходных кодов, или воспользоваться сторонним репозиторием IUS Community.

Первоначальная настройка и создание репозитория

Перед началом работы с Git нужно указать свое имя и email, которые в дальнейшем будут записываться в историю изменений при каждом коммите. В будущем это позволит понять, кто именно внес те или иные изменения.

Откроем любое из приложений — Git Bash или Git CMD. Первое — это командная строка в стиле Linux, второе — командная строка в стиле Windows. Выбирайте то, что вам ближе. Мы выберем Git Bash и выполним две команды:

git config --global user.email "git-user@selectel.ru"
git config --global user.name "Selectel Git User"

Теперь Git полностью готов к работе. Давайте создадим репозиторий и зафиксируем в нем первое изменение (сделаем коммит). Для начала создадим каталог для будущего репозитория и сразу перейдем в него:

mkdir first-repo && cd first-repo

Создаем новый репозиторий в этом каталоге:

git init

Увидим ответ:

Initialized empty Git repository in C:/Users/git_user/first-repo/.git/.

Это означает, что в директории создан новый репозиторий. Далее создадим текстовый файл, назовем его README.md, и напишем в нем любой текст. Но сам по себе этот файл не попадет в следующий коммит. Мы должны проиндексировать изменения, то есть явно сказать Git-у, что этот файл нужно учитывать в следующем коммите:

git add README.md

Далее введем команду:

 git commit

Откроется текстовый редактор, который мы выбирали на этапе установки Git. Тут нам нужно ввести комментарий для коммита, то есть кратко описать изменение, которое мы сделали. Мы напишем такой комментарий:

Картинка с сайта: selectel.ru

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

Сохраним файл и закроем редактор. Увидим примерно следующее сообщение:

[master (root-commit) 2b8f7a5] Add readme file
 1 file changed, 3 insertions(+)
 create mode 100644 README.md

Мы успешно сделали первый коммит.

Работа с Git в визуальном интерфейсе

Сам по себе Git — это утилита командной строки. Но не всем может быть удобно запоминать и писать команды в терминале, поэтому часто разработчики пользуются графическим интерфейсом. Есть несколько вариантов:

• Встроенный GUI. В базовой установке Git есть две простые утилиты: gitk и git gui. Но у них довольно старый интерфейс и пользоваться ими не всегда удобно.
• Отдельные графические утилиты. Они могут быть понятны и красивы, но неудобны тем, что код нужно писать в одной программе, а для работы с Git нужно переключаться в другую. Примеры таких программ: GitKraken, Sourcetree, GitAtomic. Большой список таких клиентов есть на официальном сайте Git.
• Встроенные в IDE или текстовый редактор. В большинстве популярных редакторов кода или IDE уже есть поддержка Git. Как правило, ничего дополнительно настраивать не нужно. Мы рассмотрим именно такой вариант на примере редактора VSCode.

Откроем директорию с репозиторием в редакторе VSCode. Внесите любое изменение в файл README.md и сохраните изменения. Обратите внимание, что в левой части редактора кое-что изменилось:

1. Файл README.md подсветился желтым цветом, а рядом с ним появилась буква M (означает Modified — изменен).
2. На панели Source Code появилась цифра 1, означающая, что есть одно изменение, которое можно зафиксировать.

Перейдем на панель Source Code. Слева находится список файлов, которые были изменены. Если кликнем на файл, то увидим какие именно изменения мы внесли: в этом случае добавили новую строчку This is the second commit.

Картинка с сайта: selectel.ru

Теперь давайте зафиксируем наши изменения. Рядом с названием файла нажмем на «плюс», чтобы проиндексировать его. Это аналогично команде git add, которую мы выполняли ранее. Затем в поле Message внесем комментарий и нажмем кнопку Commit. Это аналогично команде git commit.

Поздравляем, вы сделали уже два коммита в свой репозиторий!

Заключение

Итак, мы рассмотрели процесс установки Git под Windows, рассказали об основных параметрах установки и последующей настройки. Увидели, как репозиторий и внести в него первый коммит. Познакомились с работой в командной строке и с помощью графического интерфейса.