1.1 Введение — О системе контроля версий
Эта глава о том, как начать работу с Git. Вначале изучим основы систем контроля версий, затем перейдём к тому, как запустить Git на вашей ОС и окончательно настроить для работы. В конце главы вы уже будете знать, что такое Git и почему им следует пользоваться, а также получите окончательно настроенную для работы систему.
О системе контроля версий
Что такое «система контроля версий» и почему это важно? Система контроля версий — это система, записывающая изменения в файл или набор файлов в течение времени и позволяющая вернуться позже к определённой версии. Для контроля версий файлов в этой книге в качестве примера будет использоваться исходный код программного обеспечения, хотя на самом деле вы можете использовать контроль версий практически для любых типов файлов.
Если вы графический или web-дизайнер и хотите сохранить каждую версию изображения или макета (скорее всего, захотите), система контроля версий (далее СКВ) — как раз то, что нужно. Она позволяет вернуть файлы к состоянию, в котором они были до изменений, вернуть проект к исходному состоянию, увидеть изменения, увидеть, кто последний менял что-то и вызвал проблему, кто поставил задачу и когда и многое другое. Использование СКВ также значит в целом, что, если вы сломали что-то или потеряли файлы, вы спокойно можете всё исправить. В дополнение ко всему вы получите всё это без каких-либо дополнительных усилий.
Локальные системы контроля версий
Многие люди в качестве метода контроля версий применяют копирование файлов в отдельный каталог (возможно даже, каталог с отметкой по времени, если они достаточно сообразительны). Данный подход очень распространён из-за его простоты, однако он невероятно сильно подвержен появлению ошибок. Можно легко забыть в каком каталоге вы находитесь и случайно изменить не тот файл или скопировать не те файлы, которые вы хотели.
Для того, чтобы решить эту проблему, программисты давным-давно разработали локальные СКВ с простой базой данных, которая хранит записи о всех изменениях в файлах, осуществляя тем самым контроль ревизий.
Одной из популярных СКВ была система RCS, которая и сегодня распространяется со многими компьютерами. RCS хранит на диске наборы патчей (различий между файлами) в специальном формате, применяя которые она может воссоздавать состояние каждого файла в заданный момент времени.
Централизованные системы контроля версий
Следующая серьёзная проблема, с которой сталкиваются люди, — это необходимость взаимодействовать с другими разработчиками. Для того, чтобы разобраться с ней, были разработаны централизованные системы контроля версий (ЦСКВ). Такие системы, как CVS, Subversion и Perforce, используют единственный сервер, содержащий все версии файлов, и некоторое количество клиентов, которые получают файлы из этого централизованного хранилища. Применение ЦСКВ являлось стандартом на протяжении многих лет.
Такой подход имеет множество преимуществ, особенно перед локальными СКВ. Например, все разработчики проекта в определённой степени знают, чем занимается каждый из них. Администраторы имеют полный контроль над тем, кто и что может делать, и гораздо проще администрировать ЦСКВ, чем оперировать локальными базами данных на каждом клиенте.
Несмотря на это, данный подход тоже имеет серьёзные минусы. Самый очевидный минус — это единая точка отказа, представленная централизованным сервером. Если этот сервер выйдет из строя на час, то в течение этого времени никто не сможет использовать контроль версий для сохранения изменений, над которыми работает, а также никто не сможет обмениваться этими изменениями с другими разработчиками. Если жёсткий диск, на котором хранится центральная БД, повреждён, а своевременные бэкапы отсутствуют, вы потеряете всё — всю историю проекта, не считая единичных снимков репозитория, которые сохранились на локальных машинах разработчиков. Локальные СКВ страдают от той же самой проблемы: когда вся история проекта хранится в одном месте, вы рискуете потерять всё.
Распределённые системы контроля версий
Здесь в игру вступают распределённые системы контроля версий (РСКВ). В РСКВ (таких как Git, Mercurial, Bazaar или Darcs) клиенты не просто скачивают снимок всех файлов (состояние файлов на определённый момент времени) — они полностью копируют репозиторий. В этом случае, если один из серверов, через который разработчики обменивались данными, умрёт, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Каждая копия репозитория является полным бэкапом всех данных.
Более того, многие РСКВ могут одновременно взаимодействовать с несколькими удалёнными репозиториями, благодаря этому вы можете работать с различными группами людей, применяя различные подходы единовременно в рамках одного проекта. Это позволяет применять сразу несколько подходов в разработке, например, иерархические модели, что совершенно невозможно в централизованных системах.
Git: простое руководство о том, как стать мастером контроля версий
Git — это мощная система контроля версий, которая помогает управлять проектами и сотрудничать с другими разработчиками. Без хорошего руководства ее довольно сложно освоить. Этот гайд поможет разобраться в том, как используется Git, и предоставит инструменты, с помощью которых вы станете мастером контроля версий.
Что такое Git?
Git — это распределенная система контроля версий, которая позволяет разработчикам отслеживать изменения в коде с течением времени. Она хранит все версии проекта в репозитории, предоставляя пользователям возможность переходить от одной версии к другой. Кроме того, она позволяет нескольким программистам работать над одним проектом одновременно, что значительно упрощает совместный труд.
Начало работы с Git
Первый ваш шаг к освоению Git — установка его на компьютер. После этого можно создавать репозитории и отслеживать изменения в коде. Упростить работу позволит графический интерфейс пользователя (GUI), например GitHub Desktop и SourceTree.
Основы контроля версий
После установки Git важно понять основы контроля версий. Контроль версий позволяет отслеживать изменения в коде с течением времени и при необходимости возвращаться к предыдущим версиям. Вы также можете использовать ветви, чтобы создавать отдельные версии проекта для различных целей, например для разработки и производства.
Для получения полного списка команд Git используйте команду git -help в командной строке (Windows), терминале (Mac OS X) или оболочке (Linux).
Вот некоторые из основных команд Git.
- git clone загружает копию репозитория Git с удаленного сервера на локальный компьютер.
- git add добавляет файлы в область хранения, где они могут быть подготовлены для коммитинга.
- git commit сохраняет изменения, внесенные в файлы в локальном репозитории.
- git push загружает локальные коммиты в удаленный репозиторий.
- git pull выполняет выгрузку изменений из удаленного репозитория и их слияние с локальным репозиторием.
- git branch используется для создания и просмотра ветвей в репозитории Git. Ветви позволяют нескольким специалистам одновременно работать над различными аспектами проекта, не затрагивая основную кодовую базу.
- git merge объединяет в одну ветку изменения, внесенные в разных ветках.
Кроме этого, в вашем распоряжении есть множество более продвинутых команд, которые можно использовать для решения специфических задач.
Продвинутые технологии Git
После освоения основ контроля версий, приступим к изучению более продвинутых технологий, таких как ветвление и слияние. Ветвление позволяет создавать отдельные версии проекта для разных целей, а слияние — объединять несколько ветвей в одну единую версию. Можно также использовать теги, чтобы отмечать определенные моменты в истории проекта, что в дальнейшем облегчит поиск нужных версий.
Ниже представлены продвинутые команды Git.
- git stash сохраняет изменения, которые еще не были закоммичены, и возвращает репозиторий к его предыдущему состоянию. Это полезно, когда нужно перейти на другую ветку, но при этом не коммитить изменения.
- git rebase интегрирует изменения из одной ветки в другую, что позволяет переписать историю коммитов ветки, создавая впечатление, что изменения произошли одновременно, а не как серия отдельных коммитов.
- git bisect выполняет двоичный поиск в истории коммитов, чтобы определить, в каком коммите была обнаружена ошибка. Эта команда может быть использована для быстрого поиска источника проблемы в большой базе данных.
- git cherry-pick позволяет выбрать определенные коммиты из одной ветки и применить их к другой ветке. Это полезно, когда нужно включить изменения из одной ветки в другую, но при этом не выполнять слияние всей ветки.
Совместная работа с помощью Git
Git значительно упрощает совместную работу, позволяя нескольким разработчикам одновременно трудиться над одним проектом. Вы можете использовать ветви и теги для отслеживания различных версий и убедиться, что все работают над одной и той же версией проекта. Можно также применять запросы на включение изменений (пул-реквесты) для проверки изменений до их слияния с основной веткой. Это гарантирует, что все будут на одной волне, когда дело дойдет до изменений кода.
Как видите, не стоит пугаться Git — откройте его возможности и начните использовать их уже сегодня!
Работа с распределенной системой контроля версий Git на примере GitHub
Предупреждение по использованию:
Данная публикация является учебной для освоения основ системы контроля версий git, на примере использования GitHub. Это не руководство к действию. Вы должны понимать, то что вы делаете применяя команды и идеи изложенные в публикации. Не спешите применять сказанное к вашим рабочим проектам. Создайте черновой проект, локальный репозиторий. Потренируйтесь на нем. Создайте свой учебный проект на GitHub. Когда вы хорошо будете понимать, что и как работает, только тогда вы сможете применить ваши знания в рабочих проектах. Публикация не является переводом какой либо работы. Это авторская работа с целью прояснить некоторые вопросы. Более подробно смотрите раздел: «Цель публикации».
Небольшая ремарка:
Первый и может быть наиболее важный вопрос, который следовало бы рассмотреть — это безопасность системы для разработчика. Если в организации вашу сеть защищает системный администратор. То обычному пользователю приходится эти вопросы решать самостоятельно.
Этот вопрос далеко не праздный.
Что не должно попасть в удаленный репозиторий:
Лишние файлы конфигурации, исполняемые файлы, временные файлы, ключи к репозиторию, платежные ключи(когда вы работаете над платежными сервисами и системами наподобии Amazon). В ветки master и release не должны попасть изменения от начинающих, неопытных программистов и некачественный код, не прошедший тестирование.
Обязательно прочитайте в документации: что не должно попадать в GitHub и как настроить .gitignore.
Система контроля версий довольно сложная штука. Но пусть вас это не пугает. Попробуем разобраться. Дать определения, и внести ясность. Если вы работаете один над своим проектом, то вам даже не обязательно регистрироваться на сервере. Вы можете просто установить себе Git и работать с системой контроля версий локально. Вам для локальной работы над проектом не обязательно даже будет подключение к интернету. Репозиторий который вы создаете локально — это фактически такой же репозиторий как на сервере, только без возможности работать над проектом распределенной команды разработчиков. Система контроля версий — по существу это реализация права программиста на ошибку в своем коде. Как вы помните «человеку свойственно ошибаться». Так вот, ошибаться программисту следует гораздо меньше. И, чтобы вернуться к своему коду и исправить ошибку, добавить функциональность и существует такая замечательная система, как система контроля версий. Кроме того использование системы контроля версий — это более эффективный менеджмент.
Ответьте на вопрос: В чем заключается работа в команде и вы поймете насколько управление проектом становится более эффективным с системой контроля версий. Еще одно преимущество: Система контроля версий облегчает процесс ревью(пересмотра, доработки) кода. Следующее преимущество: Автоматическое разрешение конфликтов. То есть объединение, например разных версий методов, сделанных разными разработчиками в одну ветку. Здесь, в данном материале я не рассматриваю плагины для git в IDE. Здесь рассматриваются только общие вопросы работы с git и работы с удаленным репозиторием на GitHub.
Контрольные вопросы:
В чем заключается экономия времени при использовании системы контроля версий?
В чем преимущества использования системы контроля версий?
Что такое Git?
Как начать использовать git?
Как начать использовать GitHub?
Основные(наиболее часто используемые) команды Git.
Какие сервисы существуют для Git?
Как работать с локальным репозиторием?
Как работать с распределенным репозиторием?
Git-хостинг на разных условиях предлагают многие компаний.
Довольно известные из них: Github, Sourceforge, Google Code, GitLab, Codebase и тд.
Сервисы git в порядке популярности(тут, чтобы не возникло холивара, допишу: По моему мнению):
1. Ваш локальный сервис, использование git только локально
2. GitHub
3. BitBucket
4. GitLab
Про использование своего git сервера вы можете прочитать на хабре >>>
В данной публикации я рассматриваю в основном работу с сервисом GitHub.
Цель публикации: Коротко рассказать что такое Git.
Описать некоторые, основные команды консоли Git. Хотя в интернет существует довольно много описаний работы с git, многое из документации может показаться запутанным и некоторые определения раскрыты не полностью. Что может ввести начинающих в заблуждение. Некоторые определения следует написать в более развернутом виде, для ясности понимания.
Также с практическими примерами намного легче освоить систему. Цель статьи сделать небольшой обзор о системе Git. Показать как использовать некоторые команды, для более быстрого освоения начинающими. Показать как настроить систему для конкретного использования. Следующая цель, предотвратить бездумное использование тех или иных команд Git.
Предметная область и основные термины
Git — одна из распределенных систем контроля версий.
GitHub — один из сервисов для использования системы контроля версий Git.
repository — некоторое хранилище файлов, ссылок на изменения в файлах
commit — отслеживание изменений, сохраняет разницу в изменениях
HEAD — (специальный указатель) символическая ссылка на последние изменения. Примечание: Не обязательно ссылается на commit. Может указывать на ветвь. Состояние — «Detached HEAD»
HEAD используется репозиторием для определения того, что выбрано с помощью checkout.
Обратите внимание на это различие: «head» (в нижнем регистре) относится к любому из названных заголовков в хранилище; «HEAD» (верхний регистр) относится исключительно к текущему активному заголовку(ссылке). Это различие часто используется в документации Git. HEAD может указывать на именованную вершину какой-либо ветки или на commit.
Объекты Git. Четыре типа объектов: Blob, Tree, Commit и References.
Ветвь определяется не в самом Git, а наследуется от операционной и файловой систем.
Более подробно об объектах Git вы можете прочитать в документации.
git сервисы — сервисы предоставляющие услуги для пользователей git.
working directory — рабочий каталог на вашем компьютере
staging area — область подготовленных файлов или рабочая область
branch — ветка, состоит из набора коммитов, обычно ссылается на последний коммит
merge — слияние, слияние веток в одну
pull — втянуть, взять проект с сервера, получить изменения из удаленного репозитория
push — вытолкнуть, отправить изменения на сервер
Символы:
# — в данном случае символ комментария
<> — угловые скобки, там где вам нужно вписать нужное исключая эти скобки
$ — приглашение ввода в терминале
Небольшое вступление
Хотел написать небольшую шпаргалку по git, а получилась довольно длинная публикация.
Но без объяснения тех или иных терминов и некоторой вводной теоретической части не обойтись.
Git — одна из систем контроля версий.
Предназначена, в основном, для работы распределенной команды разработчиков.
То есть разработчики могут находиться в разных концах света и работать над одним проектом.
Нет Git используют не только разработчики, но и дизайнеры, писатели, редакторы, проектировщики, переводчики. GitHub часто используют hr специалисты и hr менеджеры для поиска успешных кандидатов на те или иные вакасии в различных областях. Для математического анализа успешности проектов.
Система Git очень экономична и не требует рассылки большого количества файлов. Отслеживаются и пересылаются изменения в файлах и ссылки на эти изменения. То есть основная рассылка это рассылка разницы в ваших редактированиях.
Отсылаются только различия в папках и файлах. В любой момент времени вы можете возвратиться к тому или иному состоянию системы. Многие компании уделяют внимание хорошей и быстрой коммуникации между сотрудниками. В этом отношении, система контроля версий предоставляет большие возможности. Всю мощь и гибкость системы управления версиями вы сможете ощутить после изучения некоторого теоретического материала и применения на практике.
История создания
Теоретическая часть(коротко)
Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux
Git свободная система и распространяется она под лицензией GNU GPL 2.
Основная задача системы управление версий — это упрощение работы с потоками изменяющейся информации. Главной парадигмой системы управления версий является локализация данных каждого разработчика проекта. Каждый разработчик имеет на своей машине локальный репозиторий. В случае необходимости изменения отправляются из локального репозитория в удаленное хранилище в определенную ветку. И любой разработчик из распределенной команды может скачать новые изменения в проекте, чтобы продолжить совместную работу над проектом. Тут я сделаю некоторую ремарку. Важно соблюдать стандарты по оформлению кода и работе с системой в вашей организации. Стандарты облегчают взаимодействие между разработчиками, экономят время, облегчают понимание того что вы делаете. Некоторая этика и культура по оформлению кода, по оформлению и структурированию рабочего процесса помогает разработчикам лучше и быстрее понимать друг друга.
Какие существуют системы управления версиями:
1. Централизованные
2. Децентрализованные(распределенные)
В централизованной системе управления версий код хранится на сервере. Все разработчики в команде имеют доступ к централизованному хранилищу. Однако существуют минусы такой организации работы. У разработчика нет своего локального репозитория, а есть только копия данных с сервера. В случае выхода из строя сервера команда не сможет продолжить работу над проектом. Второй минус использования централизованной системы управлени версиями в сложности досупа к одному ресурсу одновременно нескольким разработчикам.
В распределенной системе управления версий, кроме версии репозитория на сервере, у каждого разработчика есть свой репозиторий. Это позволяет быстро восстановить актуальное состояние нашего программного обеспечения.
Некоторое отступление от темы: Зачем я так много привел цитат?
Ответ самый простой. Чтобы в дальнейшем дать более точные и ясные определения.
Практическая часть
Для использования системы git вам нужно:
1. Установить программу git на вашей системе.
2. Настроить программу и проверить её работоспособность локально
3. Зарегистрировать ваш аккаунт на GitHub
4. Создать локальный репозиторий или копировать репозиторий существующего проекта
5. Написать файл README.MD.
6. В случае, если вы начинаете проект, создать удаленный репозиторий
7. Фиксировать изменения локально
8. Отправлять изменения на GitHub
9. Зарегистрировать аккаунты разработчиков вашего проекта
10. Выдать им ссылку на проект
1. Установка git
1. После установки вы можете кликнуть правой кнопкой мышки на папке в проводнике Windows и выбрать открыть «Git Bash Here». Git Bash Here — означает отрыть терминал git здесь.
В терминале введите команду
проверить версию вашего git.
В Linux,(Ctrl+Alt+T — терминал, если у вас не назначены другие горячие клавиши) откройте терминал и введите
В случае успешной установки на консоль выведется версия вашего git.
2.Настройка программы Git
Примечание:
Тут следует упомянуть, что настройку Git вы осуществляете на нескольких уровнях.
То есть некоторые настройки вы делаете для определенного пользователя операционной системы(не системы git, а операционной системы). Другие настройки вы делаете для всех пользователей операционной системы. Далее вы можете делать настройки для определенной папки(локально). Вы делает настройки для репозитория находящегося на сервере. Эти настройки вы можете не делать, если работаете только со своим локальным репозиторием.
В данной публикации я рассматриваю команды консоли в основном Windows git-bash.
Более подробно об отличиях вы можете посмотреть в документации. Упомяну только что есть некоторые отличия. Например в параметрах пути к файлам и папкам. В Windows используется / — слеш, а в Linux обратный слеш \. Хотя в Windows вы можете самостоятельно настроить на использование обратного слеша.
Настройка пользователя и емейл:
Чтобы ввести настройки только одного репозитория, перейдите в его папку и сделайте то же без —global:
Настройка внешнего редактора.
#команда для Linux.
Вы можете выбрать другой текстовый редактор. Например не emacs, a vi или nano или другой на ваше усмотрение.
В Windows, такой командой вы можете задать текстовый редактор, например notepad++.
Для x64 Windows вы можете использовать команду(только пропишите свой путь):
Настройки git хранятся в файлах.
Git проверяет 4 места для файла конфигурации(здесь в Linux):
Файл вашего компьютера .gitconfig.
Ваш пользовательский, файл вашего пользователя .gitconfig файл находится в
/.gitconfig.
Второй пользовательский файл конфигурации, расположенный в $ XDG_CONFIG_HOME/git/config или $HOME/.config/git/config.
Конфигурационный файл локального репозитория: .git/config
Каждый файл добавляет или переопределяет параметры git, определенные в файле над ним.
Конфигурация системы.
Конфигурация пользователя.
Конфигурация, специфичная для репозитория.
Вы можете просмотреть файлы конфигурации
#для системы и всех пользователей
Проверка настроек вашей конфигурации git:
Если список большой, вы можете пролистывать его с помощью стрелок клавиатуры или «pg up», «pg dn». Для выхода клавиша q.
#какая конфигурация, где установлена:
Для чего нужно рассмотреть консольные команды? Ведь существуют UI.
Часто в консоли вы можете сделать, что-то гораздо быстрее. С помощью набора консольных команд вы сами в будущем сможете автоматизировать процесс. Консольные команды более гибкий инструмент. Почему? Да потому что ваш UI может и «не знать» о существовании той или иной команды. UI может вообще отсутствовать как таковой, например на сервере ввиду своей небезопасности. На первом этапе консольные команды во многом помогут в общем понимании того как работает система. Все их запоминать нет необходимости. Вы в любой момент сможете найти справку по той или иной команде. Теоретические знания, без которых никуда, лучше усваиваются с применением на практике.
Команды Git(консольные)
Опции:
-C — использовать указанную папку репозитория вместо текущей папки;
-c параметр=значение — использовать указанное значение параметра конфигурации;
-p — прокручивать весь вывод с помощью less;
Инициализация локального репозитория.
1. Переходим в папку проекта.
2.
3. Папку. Точка после add отделенная пробелом.
Можно добавить отдельный файл
Например
Таким образом мы говорим — отслеживать изменения нашего файла.
Для добавления всего в папке рекомендуют использовать команду
4. Создание commit
-m «комментарий» #аргумент создания комментария коммиту. Ваши изменения будут уже с осмысленным комментарием.
Вы можете использовать полное имя ключа, вместо его сокращения. К примеру, вместо -m вы можете использовать —message=«комментарий»
Тут нужно сделать некоторое замечание. Чтобы использовать русские буквы в комментариях, нужно сделать предварительные настройки. Вам нужно настроить кодировку символов в системе, кодировку символов в текстовом редакторе или IDE, кодировку символов в терминале, кодировку символов в git. Другой момент: Windows «не любит» одиночные апострофы, поэтому коментарий заклечен в кавычки. На Linux есть возможность использовать апострофы при оформлении коментария к коммиту.
6.
Показывает информацию — какая ветка текущая.
Какие файлы изменены и тд. Команда показывает, что находится в рабочей области(в staging area).
Ветки. Branches
Ветка(branch) — ссылка на определенный коммит.
Создание ветки.
, используйте для имени латинские буквы. Тут есть одно замечание. Когда мы создали ветку с некоторым именем, текущей осталась ветка, которая была выделена до этого. Ну например master. И если после создания ветки мы скажем git commit, то будет продолжена ветка master. Не понимание этого часто приводит к ошибкам.
Совет: Чтобы продолжить новую ветку нужно её создать, потом переключиться на неё и сделать commit.
1. Создаем ветку:
2. Переключаемся на созданную ветку:
3. Делаем commit:
Теперь у нас есть вторая ветка с именем feature.
Объединение веток(merge).
Объединение веток создает коммит от двух родителей, от текущей ветки и ветки указанной в команде git.
1. Переключаемся на ветку master
2. Сморим какая ветка текущая
3. Объединяем ветки
Мы можем сделать по другому. Переключиться на ветку feature и объединить её с веткой master
1.
2. , в данном случае feature c веткой master.
Просмотр доступных веток:
stash — стек, временное хранилище
Не путайте со stage, это не одно и то же.
Команда сохраняет все не закомиченные изменения во временное хранилище и сбрасывает состояние ветки до HEAD.
Стеш(stash) предназначит для того, что бы спрятать не нужные на данный момент изменения, потому он и называется stash, в переводе — прятать, припрятывать.
рис 1.
На рисунке показана подготовка папки на локальном компьютере для git.
Добавление в staging area. Добавление изменений в локальный репозиторий(git commit).
Отправка в удаленный репозиторий(git push).
На данной схеме не показана сущность stash.
рис 2.
На диаграмме рис 2. показана работа команд add, commit all, commit, reset, git reset head, git update index.
Untacked files — непроиндексированные файлы.
Working tree — ваша рабочая папка
Index — индексация файлов
Commit — изменения файлов
Здесь нужно внести некоторую ясность. Диаграмма относится к вашему локальному репозиторию. Но это другой вид диаграммы. Это как будто мы рассматриваем работу git c различных точек, под «разным углом». Показан некоторый жизненный цикл индексации изменений локального репозитория.
Работа с командами:
Очень полезные команды. Рассмотрите их самостоятельно.
Работа с удаленным репозиторием
Далее я перейду к описанию работы с удаленным репозиторием.
Вы можете работать с удаленным репозиторием и вашим проектом через протокол [url]https://,[/url]
то есть в вашем браузере(chrome, mozilla, opera и других).
GitHub.com >>>
Интерфейс GitHub на английском языке.
Для начала, вам нужно зарегистрироваться на GitHub, если вы этого еще не сделали или
подключить нужную ветку и отправить изменения локального репозитория.
Узнать как зарегистрироваться вы можете на самом сайте GitHub.
Перед использованием удаленного репозитория у вас должен быть локальный проинициализированный репозиторий.
В папке на локальном компьютере:
Подключить ветку на удаленном(в данном случае GitHub) компьютере:
«имя_ник_пользователя» — в данном случае ник пользователя удаленного репозитория.
«ИмяРепозитория» — в данном случае это имя вашего уже созданного заранее репозитория на GitHub
Показать какие пути назначены:
Обычно там одна ветка origin.
То есть это не сама ветка, а её сокращенное название ассоциированное с репозиторием.
Вы можете добавить, ассоциировать еще одну ветку на удаленном репозитории.
имя_удаленного_реп — имеется в виду короткое имя которое будет ассоциировано с удаленным репозиторием.
имя_удаленного_репозитория — имеется в виду имя репозитория на сервере. То есть имя удаленного репозитория.
Только данная команда забирает одну ветку из удаленного репозитория.
Кроме того она сливает(объединяет, merge) все изменения из удаленного репозитория с вашими локальными. Эту команду следует применять, когда вы только начинаете работать с удаленным репозиторием и у вас своих наработок в локальном пока нет.
Эта команда создает папку с именем Lимя_локальной_папки.
Берет все изменения из репозитория «github.com/имя_пользователя/имя_удаленного_репозитория.git» и сохраняет их в папке «Lимя_локальной_папки».
Здесь я написал префикс L перед именем папки, чтобы отличить локальную папку от удаленной на сервере.
Диаграмма ниже показывает отличие работы с локальным репозиторием и с репозиторием на GitHub
[url]https://greenido.files.wordpress.com/2013/07/git-local-remote.png?w=696&h=570[/url] 
Из данной диаграммы вы можете видеть, как работать с локальным репозиторием и как работать с репозиторием на сервере. Показаны только несколько команд для краткости и ясности.
Ваш локальный репозиторий находящийся на одной вашей рабочей станции — это такой же репозиторий. Вы можете не регистрироваться на GitHub или других серверах, а работать локально. Вам даже не нужно для этого подключения к интернет. У вас будет локальный репозиторий и контроль версий. Такие же ветки, по которым вы можете переключаться, объединять их и тд. То есть полноценно работать локально, как с сервером.
При желании, вы сможете потом отправить их на сервер.
Чтобы некоторые ваши файлы не попадали в репозиторий.
Вы хотите чтобы некоторые файлы не индексировались и не попадали в репозиторий?
Вам нужно создать файл с именем .gitignore.
В терминале cmd windows:
Пустой созданный файл .gitignore вам ничего не дает. Чтобы некоторые файлы не отправлялись на сервер, вам нужно задать в этом файле правила.
Вы можете скачать готовый файл .gitignore с GitHub. Там есть специальный репозиторий, в котором сохраняются шаблоны .gitignore для разных языков и фреймворков.
Репозиторий gitignore >>>
По умолчанию файл .gitignore не добавляется в репозиторий.
О файле .gitignore вы можете прочесть в документации:
git-scm.com/docs/gitignore
Приводится пример файла и кратко описывается его синтаксис.
Вы можете создать глобальный файл для пользователя
Теперь вам нужно узнать куда ведет ссылка и создать файл.
Вам осталось создать этот файл. Откройте терминал(В Windows cmd).
Вы можете скопировать готовый файл отсюда >>>
Откройте ваш пустой файл .gitignore_global в текстовом редакторе и скопируйте текст из готового файла в ваш. Сохраните файл.
рис 3.
На данной диаграмме показана работа команд: git add, git commit, git push и git fetch.
Команда fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент.
Проще говоря, состоит из двух команд: и .
Опции(ключи) -n, —dry-run #многие команды git имеют данные ключи. Эти опции нужны для того чтобы посмотреть какие изменения сделает команда.
То есть, вы можете увидеть результат выполнения данной команды и затем применить её при уверенности без ключей -n, —dry-run
Модели ветвления в Git:
Для чего нужны модели ветвления?
Для лучшей организации потока работы(Workflow). Для стандартизации. То есть в вашей организации может быть принята, в зависимости от целей некоторая модель ветвления.
Central Workflow
Developer Branch Workflow
Feature Branch Workflow
Issue Branch Workflow
Forking Workflow
Patch Workflow
Central Workflow (центральный рабочий процесс) в этом контексте определяется как «вы отправляете изменения тому же репозиторий, из которого вы обычно получаете свои последние вышестоящие изменения», независимо от того, используете ли вы rebase или merge. (pull = fetch + merge или fetch + rebase, в зависимости от конфигурации и параметров)
Feature Branching являет логическим расширением Central Workflow (центрального рабочий процесса). Основная идея рабочего процесса Feature Branch: разработка всех функций должна осуществляться в выделенной ветви вместо основной ветви. Главная ветвь никогда не должна содержать неработающий код. Это является большим преимуществом в средах непрерывной интеграции.
Gitflow Workflow
Рабочий процесс Gitflow был впервые опубликован в блоге Винсента Дриссена от nvie за 2010 год. Рабочий процесс Gitflow определяет строгую модель ветвления, разработанную для выпуска проекта. Этот рабочий процесс не добавляет каких-либо новых концепций или команд помимо того, что требуется для рабочего процесса Feature Branch. Вместо этого он назначает очень конкретные роли различным ветвям и определяет, как и когда они должны взаимодействовать.
Forking Workflow
Рабочий процесс Forking отличается от других рабочих процессов. Вместо того чтобы использовать один серверный репозиторий в качестве «центральной» кодовой базы, он предоставляет каждому разработчику серверный репозиторий. Это означает, что у каждого участника есть не один, а два репозитория Git: частный локальный и общедоступный серверный.
Рекомендации:
Не существует одного рабочего процесса, подходящего для всех разработчиков в Git. Важно разработать рабочий процесс Git, который повысит производительность вашей команды. В дополнение к командной культуре, рабочий процесс должен также дополнять деловую культуру. Функции Git, такие как ветки и теги, должны дополнять график выпуска продукции. Если ваша команда использует программное обеспечение для управления проектами для отслеживания задач, вы можете использовать ветки, соответствующие выполняемым задачам.
Вы можете найти рекомендации по использованию рабочих процессов в документации к Git.
Выводы:
Мы с вами рассмотрели работу системы git и работу с удаленными репозиториями.
В некоторой степени коснулись вопроса установки и конфигурации git, регистрации удаленного репозитория на примере GitHub. Применения git как локально, так и удаленно. А также некоторые моменты организации рабочего процесса. В одной статье невозможно рассказать обо всем. Вы можете продолжить обучение изучая материалы документации и публикации других авторов. Что меня по настоящему восхищает в git, так это проектирование и реализация хорошей экосистемы.
.gitignore. Отправка только тех файлов в репозиторий, которые необходимы
Вам может понадобится чтобы в ваш репозиторий не попадали лишние файлы.
Вы можете редактировать файл .gitignore вручную.
Для автоматического исключения некоторых файлов проекта вы можете скачать плагин для вашего IDE. Например для NetBeans 10 вы можете скачать и установить плагин с официального сайта netbeans:
plugins.netbeans.org/plugin/50356/gitignore-io
Владелец плагина: junichi11
Лицензия: Apache License, Version 2.0
Как установить:
1. Скачиваем файл в папку на локальном диске
2. Открываем IDE NetBeans
3. Tools/Plugin/Downloaded/Add Plugins
4. Указываем путь к плагину на вашем локальном компьютере.
5. Перезапуск IDE
Для IDE Intellij Idea вы можете скачать плагин «Add to gitignore»
plugins.jetbrains.com/plugin/7495—ignore
1.Переходим на сайт с плагином
2. Выбираем вашу версию IDE
3. Читаем инструкцию.
4. Скачиваем и устанавливаем
Вы можете установить плагин из IDE:
Preferences > Plugins > Browse repositories… > Search for «.ignore» > Install Plugin
После установки «Restart Idea».
Как вы знаете от версии к версии в программы вносятся изменения.
Какие изменения были сделаны для версии git 2.0: >>>
Здесь еще следует немного рассказать о безопасности использования git и то что относится к использованию различных UI для git.
Продолжение, уточнение следует…
Автор будет вынужден удалить свои публикации или скрыть их в черновики в случае отсутствия поддержки. Это не ультиматум. Если у вас есть возможность, вам пригодилось, вы можете помочь, то нажмите кнопку поддержать автора.
Цель работы
Знать понятия и компоненты систем контроля версий (СКВ), порядок и приемы работы с ними.
Уметь участвовать в командной разработке, используя конкретную СКВ — Git, а также популярный хостинг репозитариев — GitHub.
Выполнение работы
Выполнять необходимо все действия. Для удобства по тексту отмечены пункты, способ выполнения которых нужно придумать самостоятельно.
Нужно читать и осмысливать текст, который печатается в ответ на команды.
Отчет должен содержать все введенные команды, ответы системы, пояснения, что было сделано между пунктами (например, отредактирован файл), а также то, что требуется добавить в отчет по тексту задания.
Вход в терминал и создание структуры каталогов
Большая часть работы будет выполняться в терминале (командной строке). Для Windows вместе с Git поставляется программа Git Bash: эмулятор терминала Linux. Ее можно запустить из контекстного меню любого каталога пунктом Git Bash Here или из меню «Пуск».
Самостоятельно. Создайте на рабочем столе каталог lab02 для данной ЛР и запустите в нем Git Bash.
Внимание. Даже если работа выполняется в компьютерном классе, создавайте каталог на рабочем столе, а не на сетевом диске, так как git не сможет нормально с ним работать.
В терминале откроется приглашение (prompt) примерно такого вида:
Здесь важен рабочий каталог /c/Users/user/Desktop/lab02 и символ $ — начало ввода команд.
Просмотреть файлы в рабочем каталоге можно командой ls . В каталоге lab02 пусто, поэтому ls ничего не выведет.
В ходе работы будем имитировать проект с двумя участниками: Алисой и Бобом. Компьютеры Алисы и Боба имитируют папки lab02/alice и lab02/bob :
Переход между каталогами делается командой cd . Перейдем «на компьютер Алисы» — в каталог alice :
Самостоятельно. Создайте здесь каталог project и перейдите в него.
Перейти на уровень выше можно командой cd .. (две точки в конце, после cd пробел).
Самостоятельно. Перейдите из каталога проекта вверх, затем вернитесь в каталог project .
Все команды нужно заносить в отчет. Текст в Git Bash копируется при выделении, ничего нажимать не нужно. Скопированное можно вставить в любую другую программу Ctrl+V, как обычно. Для вставки в сам Git Bash из буфера обмена нажмите правую кнопку мыши или Ctrl+Insert.
Инициализация репозитария и настройка Git
Инициализируем репозитарий в текущем каталоге ( project ):
К приглашению командной строки добавилось (master) : имя текущий ветви Git. Ветвь master используется по умолчанию.
Git хранит свои данные в каталоге .git в корне репозитария — той папке, в которой сделано git init . Ее можно увидеть командой ls -A . Заходить в .git и что-либо делать там не нужно. Если удалить этот каталог, репозитарий будет безвозвратно утерян.
Git хранит три набора настроек:
Системные — для всех пользователей компьютера, как правило, их не меняют.
Пользовательские — для данного пользователя системы ( user в примере). На практике чаще всего пользуются ими. Хранятся в профиле пользователя.
Локальные — для отдельного репозитария, хранятся в нем же. Используются, если нужно работать с проектами от разного имени (примеры: личные и корпоративные проекты отдельно, Алиса и Боб в случае ЛР).
Локальные настройки имеют приоритет перед пользовательскими, а те — перед системными. Настройки Git сами не находятся под контролем версий, они специфичны для конкретного компьютера или конкретной копии репозитария.
Настроим репозитарий Алисы, чтобы коммиты были от ее имени:
Самостоятельно. Укажите данные пользователя, как в примере. Вместо IvanovII используйте свое имя и инициалы латиницей. Почта может быть любой, например, университетской, писем на нее не высылается.
Кавычки должны быть парными: или одинарными ( ‘ ), или двойными ( » ). Если нарушить парность кавычек или нажать Enter, не закрыв кавычку, ввод команды продолжится на следующей строке. В этом случае можно прервать выполнение команды, нажав Ctrl + C, затем ввести команду правильно.
Создание коммитов
Запустите CodeBlocks и создайте проект в репозитарии Алисы. Убедитесь, что не создается ненужных подкаталогов:
Project title: project
Folder to create project in: C:\Users\user\Desktop\lab02\alice
Project filename: project.cbp
Resulting filename: C:\Users\user\Desktop\lab02\alice\project\project.cbp
На этом этапе должна быть следующая структура файлов и каталогов:
Занесение файлов под контроль версий
Вернувшись в Git Bash, просмотрим состояние рабочей копии:
В отчете нужно пояснить, что означает каждая строка вывода этой команды.
Добавим файл main.cpp в отслеживаемые (в индекс):
На Windows может отобразиться такое сообщение:
Оно безвредно. Смысл в том, что Git хранит файлы с немного измененном виде, чтобы обеспечивать удобную работу с репозитарием в любой операционной системе.
Самостоятельно. Еще раз просмотрите состояние рабочей копии и поясните в отчете изменения.
Выполним коммит с файлом main.cpp и коротким сообщением:
Составление сообщений к коммитам
На практике важно, чтобы описания коммитов были информативными: в будущем по ним быстро читают историю проекта, ищут коммиты по ключевым словам. Заголовок (первая строка) должен быть коротким (желательно до 50 символов) и описывать суть изменений, потому что только он показывается в списке коммитов. Часто в заголовок включают тему (к какой части проекта относится коммит) или номер задачи в системе отслеживания ошибок:
- code: заготовка программы — изменен код (а не документация, например)
- build: update CMake version — коммит относится к сборке
- обрабатывает пустой массив | fixes #1234 — исправляет ошибку № 1234
- timer: учет високосных лет #4321 — доработка таймера по задаче № 4321
Временным незаконченным коммитам иногда приписывают WIP: (work in progress).
Из заголовка должно быть ясно, что в целом сделано и зачем (почему, для чего). Обычно нет смысла писать, какие именно файлы и функции были изменены, потому что это можно просмотреть в самом коммите. После заголовка через пустую строку может идти расширенное пояснение (тело), иногда очень длинное.
Как и для исходного кода, главный критерий — понятность и единообразие. Можно писать на русском или английском, в совершенной форме или в повелительном наклонении — но одинаково во всех коммитах.
Самостоятельно. Добавьте файл project.cbp в индекс и сделайте коммит с ним, тема — build . Сообщение после темы придумайте по смыслу изменений, например, для этого коммита подошло бы «добавлен файл проекта» или «add project file».
Создание коммитов с изменениями
Заменим тело функции main() на ввод двух чисел:
Самостоятельно. Просмотрите состояние репозитария ( git status ). В отчете поясните различия между случаем, когда добавлялся новый файл, и когда изменился существующий.
Чтобы закоммитить изменения, есть три способа, описанных ниже. Обратите внимание: Git «видит» состояние файлов на диске, поэтому после добавления изменений нужно сохранять файл в CodeBlocks. Желательно также собирать программу после изменений.
Способ 1. Сначала выбрать файлы, изменения которых должны войти в коммит, затем сделать коммит:
Этот способ удобен, если изменения присутствуют не только в тех файлах, которые коммитятся. Например, если работа над кодом уже закончена, а документация еще не дописана и коммитить ее не нужно.
Самостоятельно. Добавьте в программу вывод суммы a и b .
Способ 2. Добавить в индекс все изменения, затем сделать коммит:
Способ удобен, если измнено много файлов. После git add -u , которая добавляет в индекс измененные файлы, можно командой git add <файл> добавить в индекс новые файлы.
Самостоятельно. Добавить в программу вывод разности a и b .
Внимание. Код доработок должен быть составлен в точности так:
Дальнейшие дополнения тоже должны продолжать одну большую инструкцию вывода, а не быть отдельными. Это нужно для того, чтобы в последующих пунктах можно было наблюдать некоторые примечательные ситуации.
Способ 3. Добавить все изменения в индекс и сделать коммит в один шаг:
Способ полностью эквивалентен предыдущему и удобен, если коммит меняет только существующие файлы.
Игнорирование файлов
Можно заметить, что в выводе команды git status все время присутствуют каталоги bin/ и obj/ . Они содержат бинарные файлы (целевой *.exe и промежуточные), которые являются производными от исходного кода, уже находящегося под контролем версий. Является грубой ошибкой заносить под контроль версий продукты сборки. То же самое относится к файлам, в которых некоторые среды сохраняют, например, состояние редактора: открытые файлы и расположение окон одного члена команды не нужны в общем хранилище.
Укажем Git игнорировать присутствие каталога bin . Для этого создадим в CodeBlocks новый файл (File → New… → Empty) и запишем в него строку:
Косая черта в начале означает путь от корня репозитария (каталога project ), без нее игнорировался бы файл или каталог bin в любой подпапке. Сохраним файл в корне репозитарий под именем .gitignore , именно с точкой в начале.
Каждое правило игнорирования пишется на отдельной строке .gitignore .
Выполнив git status , можно видеть, что каталог bin не отображается.
Самостоятельно. Занесите каталог obj в список игнорируемых и убедитесь, что это удалось.
Файл .gitignore может и обычно должен находиться под контролем версий.
Самостоятельно. Создайте коммит с .gitignore , тема — git .
Просмотр истории
Работа с журналом репозитария
Журнал репозитария показывает команда git log . У нее много опций, например:
- git log —stat показывает файлы, измененные в коммитах;
- git log —oneline —decorate показывает коммиты компактно;
- git log —oneline —decorate —all —graph делает то же для всех веток.
Среди прочего, команда показывает для каждого коммита его хэш, например, d2e8af7ff9c4684d0deb60d3305474bcaf69ce5c . Некоторые версии команды показывают хэш сокращенно — краткий вариант тоже будет восприниматься командами Git, которые принимают хэш.
Если лог изменений длинный, git log показывает текст с прокруткой. Чтобы выйти из этого режима, нажмите q .
Попробуйте каждую из приведенных команд. В отчете подробно опишите, что показывается git log —stat для последнего коммита.
Коммиты можно фильтровать по разным признакам:
- git log — main.cpp показывает затрагивающие main.cpp ;
- git log —grep «code:» показывает коммиты с code: в сообщении.
Самостоятельно. Найдите сначала коммиты по теме build , затем коммиты, затрагивающие project.cbp .
Просмотр коммитов
Содержимое отдельных коммитов просматривается командой git show <refspec> , где <refspec> может быть хэшем коммита, именем ветви или выражением, которое задает, на сколько от них отступить в истории.
Просмотрим последний коммит тремя эквивалентными способами:
- git show HEAD (текущий)
- git show master (по имени ветви)
- git show d2e8af (по хэшу нужного коммита)
Для просмотра предыдущего коммита можно либо записать его хэш, либо указать, что от последнего нужно отступить на один коммит: HEAD
Самостоятельно. Просмотрите предпоследний коммит (в отчете зафиксируйте результат единожды) тремя способами.
Просмотр изменений
Внесем изменения в main.cpp : добавим печать произведения чисел, но не станем пока делать коммит.
Просмотрим изменения в рабочей копии:
В отчете необходимо пояснить все компоненты отображаемого патча.
Первый аргумент команды git diff включает показ изменений от указанного коммита до последнего, включая изменения в рабочей копии:
С двумя аргументами команда показывает разницу между указанными коммитами, например, так можно исключить изменения в рабочей копии из вывода предыдущей команды:
Самостоятельно. Просмотрите изменения между самым первым коммитом и коммитом, добавляющим вывод разности.
Использование GUI
Просмотр истории — одна из операций в СКВ, которую иногда удобнее выполнять из графической среды. Вместе с Git поставляется графическая оболочка gitk (Git GUI), которую можно вызвать пунктом Git GUI Here в контекстном меню папки проекта. Эта оболочка очень примитивная, на практике пользуются более мощными или встроенными в среду разработки.
Просмотр истории в gitk делается из меню Repository → Visualize All Branch History. Можно выбирать коммит для просмотра из списка; смотреть как изменения (Diff), так и версии файлов (Old version, New version); искать коммиты.
В отчет ничего заносить не нужно.
Откат изменений
Самостоятельно. Закоммитьте изменения в рабочей копии (вывод произведения).
Предположим, необходимо отменить (откатить) этот коммит, то есть вернуться к предыдущему. Для этого воспользуемся командной git reset :
1 указывает на коммит, к которому нужно откатить состояние рабочей копии, а ключ —hard означает, что нужно привести рабочую копию точно к состоянию выбранного коммита.
CodeBlocks (и другие среды) могут при этом показать предупреждение, что файл на диске был изменен, и предложить загрузить его заново. Следует согласиться.
Добавим над функцией main() комментарий:
Уберем изменения в main.cpp другим способом — откатив этот файл к состоянию в последнем коммите ( HEAD ):
Второй способ необходим, чтобы откатывать отдельные файлы. Аргумент HEAD необязателен, но вместо него можно указать не последний, а любой другой коммит. Это полезно, если нужно восстановить состояние одного файла таким, какое оно было в известный момент.
Обмен кодом через удаленное хранилище
Регистрация на GitHub
Зарегистрируйтесь на GitHub под именем вида KozlyukDA (своя фамилия и инициалы). При регистрации нужно указывать действующую почту — на нее придет письмо для подтверждения регистрации.
Настройка SSH
Отправлять изменения в удаленный репозитарий обычно могут не все. Так, доступ на запись к репозитариям на GitHub по умолчанию есть только у создателя (пользователя, зарегистрированного на предыдущем шаге). Загрузка комитов (доступ на чтение) из публичных репозитариев разрешена всем.
GitHub должен выяснить, что клиент, представившийся определенным пользователем, действительно им является (провести аутентификацию). Клиент git взаимодействует с сервером GitHub по протоколу SSH (secure shell), который использует для аутентификации пары ключей: открытый (public, публичный) и закрытый (private, приватный) ключ. Конкретный открытый ключ связан с конкретным закрытым. Сначала открытый ключ загружается на сервер GitHub через web-интерфейс. Затем любой клиент, который обладает соответствующим закрытым ключом, может доказать это серверу. У одного пользователя может быть несколько пар ключей, например, для рабочего и домашнего компьютера, тогда на GitHub загружаются два открытых ключа.
Внимание. Закрытый ключ является таким же секретом, как пароль пользователя. Любой, кто получит закрытый ключ, сможет вносить на сервер изменения от имени вашего пользователя. Закрытый ключ нельзя давать никому, открытый ключ можно давать свободно.
Создать пару ключей:
По умолчанию закрытый ключ записывается в файл /home/user/.ssh/id_rsa , можно оставить это значение по умолчанию (нажать Enter). Далее нужно ввести пароль, которым будет защищен ключ, и повторить его.
Пример вывода команды:
Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): (Enter)
Enter passphrase (empty for no passphrase): (ввод не отображается)
Enter same passphrase again: (ввод не отображается)
Your identification has been saved in /home/user/.ssh/id_rsa Your public key has been saved in /home/user/.ssh/id_rsa.pub
(Далее следуют уникальные для каждого ключа строки.)
Вводить пароль каждый раз, когда используется ключ, неудобно. Используют программу-агент, которая работает в фоне и предоставляет ключи другим программам, в том числе git. Пароль требуется тогда вводить один раз — при загрузке ключа в агент.
Загрузить ключ (потребуется ввести пароль):
По умолчанию ssh-add загружает
/.ssh/id_rsa , для загрузки других ключей, если это нужно, можно передавать ей путь к файлу ключа явно.
Отобразить открытый ключ можно командой:
Самостоятельно. Скопировать открытый ключ (текст) и добавить в список открытых ключей своей учетной записи GitHub. Это делается в настройках (меню пользователя в правом верхнем углу, пункт Settings), раздел SSH and GPG keys, кнопка New SSH key.
Если работа выполняется в компьютерном классе, закрытый ключ будет утерян после выхода из учетной записи (или выключении компьютера). Проще всего дома или на следующем занятии создать новый ключ и добавить его на GitHub. На практике ключи не уничтожают (кроме случаев, когда их украли), а переносят как файлы, например, при переустановке системы. Из проводника Windows файл закрытого ключа виден как C:\Users\User\.ssh\id_rsa , если понадобится его скопировать.
Отправка проекта на GitHub
Создайте репозитарий под названием cs-lab02 . Вопреки рекомендациям по ссылке, не нужно добавлять в репозитарий файл README.md или лицензию.
После создания пустого репозитария будет показана страница с инструкциями, как настроить связь с хранилищем на GitHub:
- В разделе Quick setup нужно выбрать вариант SSH.
- В разделе …or push an existing repository from the command line даны команды, которые необходимо выполнить.
При взаимодействии с удаленным хранилищем будет запрошено имя пользователя и пароль от GitHub.
Обновите страницу и убедитесь, что проект успешно загружен на GitHub. Любой файл можно просмотреть в бразуере. По ссылке Commits можно просматривать коммиты.
Получение проекта с GitHub
Предположим, к разработке проекта присоединяется Боб. Откройте новый терминал Git Bash в каталоге bob . Клонируйте проект:
На место <адреса> нужно подставить адрес, который использовался в команде git remote add (его можно всегда отобразить командой git remote -v ). Каталог — название папки для проекта: используйте project , если не указывать, это было бы название репозитария ( cs-lab02 ). Угловых скобок в команде быть не должно!
Перейдите в каталог проекта «на машине Боба» (здесь и далее это означает работу во втором терминале и над файлами в bob/project ):
Самостоятельно. «На машине Боба» настройте Git ( git config ) аналогично тому, как это делалось для Алисы в начале лабораторной работы.
Совместная работа над проектом без конфликтов правок
«На машине Боба» добавьте в программу печать произведения чисел и сделайте коммит. Просмотрите последний коммит и убедитесь, что он сделан от имени Боба.
Отправьте коммит на GitHub (используйте те же учетные данные, что и ранее):
Обновите страницу GitHub и убедитесь, что коммит попал в удаленный репозитарий. Обратите внимание, что авторство коммитов записано в самих коммитах, оно не зависит от пользователя системы или GitHub.
«На машине Алисы» (то есть в первом терминале, в каталоге alice/project ) выполните загрузку изменений:
Убедитесь, что в рабочей копии изменений еще не произошло.
Просмотрите историю всех веток:
Как можно видеть, ветка master отстает на один коммит от ветки origin/master (версии ветки master из удаленного репозитария под названием origin , то есть на GitHub).
Продвиньте ветку master к скачанной версии:
Убедитесь, что рабочая копия проекта «у Алисы» соответствует версии «у Боба».
Команда git pull автоматически делает git fetch , поэтому можно было бы применять только ее, но важно понимать, что получение изменений в Git двухфазное: загрузка новой части истории и синхронизация положения веток.
Самостоятельно. «От имени Алисы» добавьте в программу печать деления, сделайте коммит, отправьте его на GitHub и получите новую версию «на машине Боба». Иначе говоря, повторите шаги выше, поменяв местами роли Алисы и Боба.
Разрешение конфликтов правок при совместной работе
Предположим, Алиса решает добавить в программу печать максимума из чисел, а Боб — минимума.
Внимание. Код вывода в программе перед выполнением дальнейшего должен иметь следующий вид:
В противном случае код нужно привести в соответствие отдельным коммитом и синхронизировать состояние «у Алисы» и «у Боба».
«На машине Алисы» дополните программу печатью максимума, сделайте коммит и отправьте его на GitHub.
«На машине Боба» дополните программу печатью минимума, сделайте коммит и попытайтесь отправить его на GitHub. Как можно видеть, удаленный репозитарий не принимает изменений: коммит Боба основан не на последнем существующем коммите.
«От лица Боба» загрузите коммиты из удаленного хранилища и отобразите историю всех веток — результат нужно представить в отчете.
Можно видеть, что ветка master раздвоилась. Бобу нужно переместить свой коммит поверх коммита Алисы, то есть поверх origin/master :
Однако эта команда завершается с ошибкой, сообщающей о конфликте в main.cpp . Просмотрите состояние хранилища и поясните в отчете.
«На машине Боба» в CodeBlocks место конфликта будет отмечено прямо в коде. Необходимо самостоятельно:
- Удалить метки конфликта: <<<< . , . >>>> и ===== .
- Отредактировать код так, чтобы он включал и правки Алисы, и правки Боба.
- Убедиться, что программа компилируется и работает.
После того, как конфликт разрешен, нужно добавить файл в индекс и продолжить прерванную операцию rebase :
Убедитесь, что история хранилища теперь имеет желаемый вид (зафиксировав это в отчете) и отправьте изменения на GitHub.
Использование веток
Предположим, пока Боб синхронизировал изменения, Алиса решила изменить тип чисел с целых на действительные. Предполагая, что это займет время, Алиса ведет работу в отдельной ветке. На момент начала работы репозитарий Алисы не синхронизирован с GitHub, то есть последний коммит добавляет печать максимума. Все действия ведутся «на машине Алисы».
Создайте ветку double :
Переключитесь на нее:
Примечание. Создание ветки и переключение на нее можно делать одной командой: git checkout -b double . Этой команде можно передать аргумент-ссылку на коммит, где создать ветку.
Можно заметить, что текущая ветка в приглашении терминала изменилась.
Замените тип переменных a и b на double и сделайте коммит.
Переключитесь на ветку master :
Самостоятельно. Синхронизируйте ветку master «на машине Алисы» с GitHub. Просмотрите историю всех веток и занесите результат в отчет.
Слейте ветку double в master :
В результате слияния образуется специальный новый коммит (merge commit), к которому Git предлагает написать сообщение в редакторе. Строки, начинающиеся с октоторпа («решетки», # ), в сообщение не войдут.
Отправьте изменения на GitHub.
Просмотрите и занесите в отчет историю всех веток репозитария.
Редактор Vim
Vim — продвинутый текстовый редактор. Он не является частью Git, но популярен в системах семейства *nix, поэтому предлагается по умолчанию. Не обязательно его использовать, но нужно знать минимум для обращения с ним.
После запуска Vim находится в так называемом нормальном режиме. Чтобы начать вводить текст, нужно перейти в режим вставки, нажав i (одну клавишу). В режиме вставки можно набирать текст обычным образом. Вернуться в нормальный режим можно нажатием Escape. Находясь в нормальном режиме, можно сохранить сообщение и выйти из Vim нажатием ZZ (две заглавные Z, то есть Shift+Z два раза).
Если вместо Shift+Z нажать Ctrl+Z, Vim будет приостановлен, а коммит останется незавершенным. В этом случае нужно вернуться в Vim командой fg в терминале.
Чтобы писать длинные сообщения, но не использовать Vim, можно указать другой редактор (например, примитивный nano ):
Формат защиты
Защита состоит из ответов на теоретические вопросы по лекции и выполнения задания, рассчитанного на 10 минут.
- Создать новый репозитарий.
- Закоммитить файл task.txt с цифрами от 0 до 9 на отдельных строках.
- Удалить строки с цифрами от 5 до 8, закоммитить.
- Просмотреть предпоследний коммит.
- Создать ветку task от предыдущего коммита.
- Переключиться на ветку task .
- Добавить в начало файла строки с буквами a , b , c , закоммитить.
- Переключиться на ветку master .
- Добавить в начало файла строки с буквами d , e , f , закоммитить.
- Слить ветку task в master , разрешив конфликт так, чтобы буквы шли по порядку.
Козлюк Д. А., Мохов А. С. для кафедры Управления и интеллектуальных технологий НИУ «МЭИ», 2022 г.