Что такое Git?
Git – это система контроля версий. Система контроля версий – это система, позволяющая группе людей совместно работать над кодом, не рискуя случайно перезаписать чужую работу. Она также позволяет группе отслеживать, кто менял код и когда это произошло, и поэтому можно легко докопаться до источника проблемы.
Зачем нужен Git?
Представьте себе редактирование файла без использования систеым контроля версий. Допустим, у вас есть рецепт шоколадного пирожного. Вы отправляете рецепт своему другу, и он решает изменить в нем количество какао. Когда он вносит свое изменение – оно отражается только в его версии файла, а не в вашей. Ваши файлы теперь различаются. Если вы внесете изменение количества ванили, расхождений между вашими версиями станет еще больше.
Можно легко увидеть, что для программного кода это недопустимо! В системе контроля версий есть одна «мастер-версия» – одобренная версия кода. Эта мастер-версия живет в GitHub (или другом сервисе контроля версий), и может быть «получена» любым пользователем. Если кто-то хочет внести изменения в код, они «вытягивают» мастер-версию кода, создают «ветку» – копию мастер-версии, вносят изменения в ветку, пушат ветку назад на GitHub, а затем создают запрос на включение кода – просьбу к кому-то провести ревью кода и слить его с веткой мастера.
Запутались? Не волнуйтесь, на примере все станет намного понятнее. Предположим, что у нас есть репозиторий исходного кода по имени «Гостевая книга думающего тестировщика». Давайте посмотрим, что произойдет, если Прюнелла Прюнвип хочет добавить свое имя в гостевую книгу.
Инструкции предполагают, что Прюнелла уже установила Git на свою машину, и создала учетную запись в GitHub.
Шаг первый: Прюнелла клонирует репозиторий исходного кода
Это часто называется «клонированием репозитория» или «выкачкой репозитория». Прюнелла делает это, переходя по URL в GitHub с исходным кодом, и нажимая на зеленую кнопку » Clone or download». Появляется выпадающее меню с URL, необходимым для клонирования кода. Она нажимает маленькую кнопку буфера обмена справа от URL, чтобы копировать его.
Затем Прюнелла открывает командную строку и переходит в папку, куда планирует положить исходный код. Оказавшись там, она вводит команду git clone и вставляет URL после этой команды. Репозиторий копируется из GitHub в новую папку.
Теперь, когда репозиторий находится в папке на ее машине, она может открыть эту папку в диспетчере файлов и посмотреть, что в ней находится. Она видит единственный текстовый файл «guestBook.txt». В нем написано следующее:
«Кристин Джеквони была здесь 11 мая 2019 года».
Шаг второй: Прюнелла создает новую ветку и добавляет в нее свои изменения
Прежде чем вносить какие-либо изменения в guestBook.txt, Прюнелла должна создать новую ветку и переключиться на нее. В командной строке она переходит в новую папку, клонированную ранее, вводя
Она может проверить, что она в мастер-ветке, введя команду git status – она получит ответ вроде этого:
Если на этом этапе Прюнелла введет git status, она получит ответ «On branch NewEntry».
Теперь, когда Прюнелла находится в правильной ветке, она внесет изменения в файл guestBook.txt, добавив в него одну строчку. Теперь он выглядит так:
«Кристин Джеквони была здесь 11 мая 2019 года.
Прюнелла Прюнвип была здесь 13 мая 2019 года».
Шаг 3: Прюнелла коммитит свои изменения и пушит их в GitHub
Теперь, когда Прюнелла внесла нужные изменения, ей нужно закоммитить и запушить его. Для начала она может прогнать git status, получая следующий ответ:
On branch NewEntry
Он говорит о том, что файл guestBook.txt был изменен. Затем Прюнелле нужно добавить файл в коммит, введя git add guestBook.txt. Теперь, если она введет git status, она увидит ответ:
On branch NewEntry
Changes to be committed:
Как только изменение закоммичено, Прюнелла может пушить его в репозиторий GitHub, вводя git push origin NewEntry. Значение NewEntry поясняет, что код должен попасть в ветку NewEntry, которая еще не существует в репозитории – по этой команде она будет создана. Origin относится к репозиторию GitHub (его также называют «удаленным»). Командная строка ответит несколькими строчками, последней из которых будет
Эта строка показывает, что в оригинальном репозитории создана новая ветка NewEntry, скопированная с локальной ветки, созданной Прюнеллой, которая тоже называется NewEntry.
Шаг 4: Прюнелла создает запрос на включение кода (пулл-реквест) в GitHub
Теперь, когда новая ветка попала в GitHub, Прюнелла может создать пулл-запрос, чтобы попросить о слиянии своих изменений с мастер-веткой. Она делает это, перейдя в репозиторий GitHub и кликнув на кнопку «New Pull Request». Это перемещает ее на страницу «Compare». Она убеждается, что в левой части сравнения находится мастер-ветка, а затем выбирает ветку NewEntry из выпадающего меню. Она может видеть, как изменился файл guestBook.txt – новая добавленная строчка подсвечена зеленым, демонстрируя разницу между двумя файлами (если бы она что-то удалила, удаленная строка подсвечивалась бы красным). И, наконец, она нажимает на кнопку «Create Pull Request».
Шаг 5. Пулл-реквест Прюнеллы одобрен и объединен
Финальный шаг в процессе изменения файлов – это ревью изменения, его одобрение и слияние, которое проводит хозяин репозитория или члены команды, имеющие права на одобрение пулл-реквеста. Теперь, если Прюнелла переключится на мастер-ветку, введя git checkout master, выкачает изменения (git pull origin master) и посмотрит на файл guestBook.txt, она увидит, что в него добавлена новая запись:
«Кристин Джеквони была здесь 11 мая 2019 года.
Прюнелла Прюнвип была здесь 13 мая 2019 года».
Вот и все! В следующий раз я расскажу о полезных для Git штуках и фокусах, но этих шагов должно быть достаточно для коммита вашего собственного кода в репозиторий команды.
Git для чего нужен тестировщику
Тренер: Арсений Батыров
Приглашенный эксперт: Виталий Котов
Курс содержит все популярные команды из Git, а также множество домашних заданий на отработку знаний.
Описание
Для хранения и работы с кодом повсеместно используются системы контроля версий. Наиболее популярная среди них — Git. Он используется буквально в каждой второй компании. С помощью этой системы можно хранить большое количество различных версий кода, разрабатывать новый функционал без помехи работающему, проверять только новые изменения. Современный тестировщик сталкивается с такими задачами каждый день — и он должен уметь работать с Git
Курс «Инструменты тестировщика: Git» содержит все популярные команды из Git, а также множество домашних заданий на отработку знаний.
На этом курсе вы научитесь:
Программа курса
Создание аккаунта на github:
Установка Git на локальный компьютер
Работа с удаленной информацией:
Работа с локальными изменениями:
Работа с git-конфигом:
Регистрация на GitLab
Регистрация на BitBucket
Технические требования
Для выполнения заданий вам потребуется:
Windows 10 / Mac OS High Sierra+ / Ubuntu 16.06+
Процессор i-серии (i3, i5, i7) или аналогичный от AMD
Минимум 4 GB RAM
1 GB на жёстком диске
Разрешение экрана минимум 1280 x 800
Внимание!
Мы ожидаем, что вы уже обладаете базовой компьютерной грамотностью. На этом курсе мы будем работать с командной строкой, графическим и консольным интерфейсами, переменными окружения, различными файловыми системами, логами, клиент-серверной архитектурой, скриншотами и видео.
Если вы не уверены, что знаете все это в должной мере — пройдите простой тест: https://www.learnqa.ru/abc_test. Если по результатам теста вы получите меньше 20 баллов — мы рекомендуем пройти короткий курс “Азбука IT”. На нем вы сможете быстро получить все необходимые знания, которые совершенно точно пригодятся вам в дальнейшем.
Формат
2 занятия (2 часа теории) + много практических заданий для самостоятельной работы + постоянные консультации тренера в чате.
Раз в неделю по четвергам до 12.00 по Московскому времени выкладываются теоретические лекции, ссылки на дополнительные материалы, домашняя работа.
Теоретическую информацию можно посмотреть в любое удобное время.
Помимо теоретической части, вас также ждут практические задания для самостоятельной работы, которые вы можете прислать тренеру на проверку. После проверки практических заданий Вы получаете подробный комментарий по своей работе и при необходимости советы по доработке. По результатам комментариев тренера Вы можете переделать работу и отправить ее тренеру еще раз.
Общение участников курса и тренера проходит и в чате группы, где можно задавать вопросы тренеру и при желании общаться с другими участниками группы. Вы можете задавать вопросы по теоретическому материалу или практическим работам, как только они у вас возникают.
Все выпускники, успешно сдавшие домашние задания, получают сертификат.
Материалы курса доступны в течение года с даты окончания.
Условия
Стоимость участия для физических лиц: 4 000 рублей за весь курс.
Стоимость участия для юридических лиц: 5 200 рублей за весь курс за одного участника. При регистрации от 3-х участников на один курс действует 15% скидка.
Организатор тренинга: ИП Батыров Арсений Георгиевич, ИНН 370207708748, ОГРНИП 316370200075996
Услуги оказываются на основании публичного договора оферты. Ознакомиться с договором можно ЗДЕСЬ.
Если Вы хотите оплатить тренинг прямо сейчас, то нажмите кнопку выше (если кнопка активна, значит можно оплачивать не беспокоясь о наличии мест). После оплаты мы пришлем письмо о регистрации на курс и подтверждение оплаты. Если Вы не получили письмо в течение рабочего дня, просто отправьте сообщение на trainings@software-testing.ru
Если Вы хотите совершить оплату позже, для гарантированного участия обязательно забронируйте место на тренинге, для этого необходимо нажать на кнопку ЗАПИСАТЬСЯ справа от тренинга и заполнить все необходимые поля
Если у Вас есть какие-то вопросы, их можно задать по указанному выше адресу.
Полезные советы по работе с Git
Цель данного материала — дать начинающему тестировщику обзорное представление касательного того, как функционирует система контроля версий продукта: от процесса клонирования репозитория до возможности создания pull-запроса. Даже если пользователь имеет существенные познания по работе с Git, все равно, данное ПО может казаться немного загадочным и интересным, в нем может происходить множество всего, что не видно на первый взгляд.
Далее поговорим о шести хитростях, которые упрощают работу с Git.
Совет №1: постоянно запускайте git status
Клиенты Git часто допускают следующую ошибку: выполнить задание и зафиксировать его, оставаясь в неправильной ветке. Не нужно быть экспертом, чтобы точно понимать, как нужно исправлять подобные ошибки.
Например, можно чаще запускать специальную команду git status. Ее можно сразу запускать после открытия командной строки и перехода внутрь репозитория, для того, чтобы ветка, в который вы находитесь, не была для вас неожиданностью в будущем.
Старт git status — также неплохой вариант выяснения, какие именно файлы в определенной ветке подверглись модификациям.
Порой, пользователи могут менять файлы с желанием отладки и забывают отменить данные изменения.
Старт git status позволит узнать вам, что конкретный файл, который не планировался модифицироваться, был отредактирован.
Совет №2: выкачивайтемастер-ветку, перед тем как начать работу в ней
Перед тем как приступать к модификации кода в своей ветке, стоит убедиться в том, что ее содержание — это самый свежий и актуальный программный код. Иначе клиент может менять код, которого уже нет в природе или банально, дублировать работу другого человека.
Убедившись в том, что в вашем распоряжении последний программный код, вы также сможете уберечь себя от конфликта слияния веток, при котором между клиентской веткой и master веткой могут возникнуть неразрешимые отличия, с которыми ПО контроля версий не понимает, как справиться.
По завершению выкачивания master-ветки, нужно не забыть переключиться на свою собственную.
Если пользователь очень часто прогоняет команду git status, то он сразу заметит, если забыл переключиться на нужную ветку.
Совет №3: добавляйте каждый измененный файл одновременно
Легкий способ добавить все пользовательские изменения в файлах одновременно — использовать специальную команду git add — A.
Перед использованием необходимо убедиться в том, что вы реально желаете добавить все эти файлы.
Совет №4: каждый commit должен содержать полезное наименование
Во время фиксации изменений в файле необязательно добавлять сообщение об этом изменении, но множество компаний будет ожидать, что вы его самостоятельно добавите.
Старайтесь облегчить жизнь себе и окружающим, обозначая commit так, чтобы в будущем в нем можно было разобраться.
«Редактирование одной строки программного кода» — не очень эффективное сообщение.
«Добавка теста для конечной точки новой контактной информации» даст намного больше информации при последующем изучении документа.
Советы по работе с Git
Совет №5: помещайте каждый git-лог в одну строку
Очень легко забыть, что конкретно вы делали в Git, посколько в нем нет интерфейса, который это может продемонстрировать.
И тут на помощь приходит так называемый git лог. Лог может в своей полноте продемонстрировать пользователю сразу несколько последних коммитов, их создателей, дату и время модификации.
Очень удобно знакомится с логами, если они сжаты в одну строку. Для этого необходимо набрать команду git log—pretty=online. Для того, чтобы выйти из лога просто введите q.
Совет №6: смотрим на разницу между пользовательскими файлами перед выполнением pull-запроса
Если клиент очень часто прогоняет команду git status, то, может быть, он не зафиксирует изменения в файлах и не отправит в удаленный репозиторий те файлы, которые не нуждаются в этом.
Но случайно зафиксировать изменения в программном коде, который под эти цели не планировался, внутри файла, который содержит необходимые изменения, все-таки получится.
Это значит, что нужно просто просмотреть diff необходимых файлов перед отправкой pull-запроса и написанием просьбы просмотреть программный код.
Для этого просто перейдите в GitHub и сравните файлы в вашей ветке и в мастере, для того, чтобы увидеть, какие именно строки кода могли измениться.
Если клиент отправил что-то неактуальное, он запросто может сменить файл на актуальный, а потом просто добавить его, зафиксировать изменения в нем, и отправить повторно в репозиторийю
Очень надеемся, что данные советы и рекомендации будут весьма полезны для многих тестировщиков и тем более программистов, которые ежедневно взаимодействуют с Git.
Git для новичков (часть 1)
Что такое Git и зачем он нужен?
С помощью Git-a вы можете откатить свой проект до более старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.
Репозиторием называют хранилище вашего кода и историю его изменений. Git работает локально и все ваши репозитории хранятся в определенных папках на жестком диске.
Так же ваши репозитории можно хранить и в интернете. Обычно для этого используют три сервиса:
Как работает
В итоге получается очень простой граф, состоящий из одной ветки ( main ) и четырех commit. Все это может превратиться в более сложный граф, состоящий из нескольких веток, которые сливаются в одну.
Об этом мы поговорим в следующих статьях. Для начала разберем работу с одной веткой.
Установка
Основой интерфейс для работы с Git-ом является консоль/терминал. Это не совсем удобно, тем более для новичков, поэтому предлагаю поставить дополнительную программу с графическим интерфейсом (кнопками, графиками и т.д.). О них я расскажу чуть позже.
Но для начала, все же установим сам Git.
Windows. Проходим по этой ссылке, выбираем под вашу ОС (32 или 64 битную), скачиваем и устанавливаем.
Для Mac OS. Открываем терминал и пишем:
Linux. Открываем терминал и вводим следующую команду.
Настройка
Вы установили себе Git и можете им пользоваться. Давайте теперь его настроим, чтобы когда вы создавали commit, указывался автор, кто его создал.
Открываем терминал (Linux и MacOS) или консоль (Windows) и вводим следующие команды.
Создание репозитория
Теперь вы готовы к работе с Git локально на компьютере.
Создадим наш первый репозиторий. Для этого пройдите в папку вашего проекта.
Теперь Git отслеживает изменения файлов вашего проекта. Но, так как вы только создали репозиторий в нем нет вашего кода. Для этого необходимо создать commit.
Отлично. Вы создали свой первый репозиторий и заполнили его первым commit.
Процесс работы с Git
Не стоит после каждого изменения файла делать commit. Чаще всего их создают, когда:
Создан новый функционал
Добавлен новый блок на верстке
Исправлены ошибки по коду
Вы завершили рабочий день и хотите сохранить код
Это поможет держать вашу ветки в чистоте и порядке. Тем самым, вы будете видеть историю изменений по каждому нововведению в вашем проекте, а не по каждому файлу.
Визуальный интерфейс
Как я и говорил ранее, существуют дополнительные программы для облегчения использования Git. Некоторые текстовые редакторы или полноценные среды разработки уже включают в себя вспомогательный интерфейс для работы с ним.
Но существуют и отдельные программы по работе с Git. Могу посоветовать эти:
Я не буду рассказывать как они работают. Предлагаю разобраться с этим самостоятельно.
Создаем свой первый проект и выкладываем на GitHub
Давайте разберемся как это сделать, с помощью среды разработки Visual Studio Code (VS Code).
Перед началом предлагаю зарегистрироваться на GitHub.
Создайте папку, где будет храниться ваш проект. Если такая папка уже есть, то создавать новую не надо.
Установите себе дополнительно анализаторы кода для JavaScript и PHP
Откройте вашу папку, которую создали ранее
После этого у вас появится вот такой интерфейс
Здесь будут располагаться все файлы вашего проекта
Здесь можно работать с Git-ом
Кнопка для создания нового файла
Кнопка для создания новой папки
Давайте теперь перейдем во вкладу для работы с Git-ом.
Откроется вот такое окно:
Кнопка для публикации нашего проекта на GitHub
Вы создали и опубликовали репозиторий на GitHub.
Теперь сделаем изменения в коде и попробуем их снова опубликовать. Перейдите во вкладку с файлами, отредактируйте какой-нибудь файл, не забудьте нажать crtl+s (Windows) или cmd+s (MacOS), чтобы сохранить файл. Вернитесь обратно во вкладу управления Git.
Если посмотреть на значок вкладки Git, то можно увидеть цифру 1 в синем кружке. Она означает, сколько файлов у нас изменено и незакоммичено. Давайте его закоммитим и опубликуем:
Кнопка для просмотра изменений в файле. Необязательно нажимать, указал для справки
Добавляем наш файл для будущего commit
Отправляем наш commit в GitHub
Поздравляю, вы научились создавать commit и отправлять его в GitHub!
Это первая вводная статья по утилите Git. Здесь мы рассмотрели:
Как его устанавливать
Как его настраивать
Как инициализировать репозиторий и создать commit через консоль
Как на примере VS Code, опубликовать свой код на GitHub
Забегая вперед, советую вам погуглить, как работают следующие команды:
P.S. Для облегчения обучения, оставлю вам ссылку на бесплатный тренажер по Git.
Git за полчаса: руководство для начинающих
В последние годы популярность git демонстрирует взрывной рост. Эта система контроля версий используется различными проектами с открытым исходным кодом.
Новичков часто пугает большое количество замысловатых команд и сложных аргументов. Но для начала все они и не нужны. Можно начать с изучения наиболее часто используемых команд, и после этого постепенно расширять свои знания. Именно так мы и поступим в этой статье. Поехали!
Основы
Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). С его помощью вы можете откатиться на более старую версию вашего проекта, сравнивать, анализировать, сливать изменения и многое другое. Этот процесс называется контролем версий. Существуют различные системы для контроля версий. Вы, возможно, о них слышали: SVN, Mercurial, Perforce, CVS, Bitkeeper и другие.
Git является распределенным, то есть не зависит от одного центрального сервера, на котором хранятся файлы. Вместо этого он работает полностью локально, сохраняя данные в папках на жестком диске, которые называются репозиторием. Тем не менее, вы можете хранить копию репозитория онлайн, это сильно облегчает работу над одним проектом для нескольких людей. Для этого используются сайты вроде github и bitbucket.
Установка
Установить git на свою машину очень просто:
Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.
Настройка
Итак, мы установили git, теперь нужно добавить немного настроек. Есть довольно много опций, с которыми можно играть, но мы настроим самые важные: наше имя пользователя и адрес электронной почты. Откройте терминал и запустите команды:
Теперь каждое наше действие будет отмечено именем и почтой. Таким образом, пользователи всегда будут в курсе, кто отвечает за какие изменения — это вносит порядок.
Создание нового репозитория
Командная строка должна вернуть что-то вроде:
Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.
Определение состояния
status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:
Сообщение говорит о том, что файл hello.txt неотслеживаемый. Это значит, что файл новый и система еще не знает, нужно ли следить за изменениями в файле или его можно просто игнорировать. Для того, чтобы начать отслеживать новый файл, нужно его специальным образом объявить.
Подготовка файлов
В git есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой commit.
В нашем случае у нас только один файл, так что добавим его:
Если нам нужно добавить все, что находится в директории, мы можем использовать
Проверим статус снова, на этот раз мы должны получить другой ответ:
Файл готов к коммиту. Сообщение о состоянии также говорит нам о том, какие изменения относительно файла были проведены в области подготовки — в данном случае это новый файл, но файлы могут быть модифицированы или удалены.
Коммит(фиксация изменений)
Коммит представляет собой состояние репозитория в определенный момент времени. Это похоже на снапшот, к которому мы можем вернуться и увидеть состояние объектов на определенный момент времени.
Чтобы зафиксировать изменения, нам нужно хотя бы одно изменение в области подготовки (мы только что создали его при помощи git add), после которого мы может коммитить:
Удаленные репозитории
1. Подключение к удаленному репозиторию
Чтобы загрузить что-нибудь в удаленный репозиторий, сначала нужно к нему подключиться. В нашем руководстве мы будем использовать адрес https://github.com/tutorialzine/awesome-project, но вам посоветуем попробовать создать свой репозиторий в GitHub, BitBucket или любом другом сервисе. Регистрация и установка может занять время, но все подобные сервисы предоставляют хорошую документацию.
Чтобы связать наш локальный репозиторий с репозиторием на GitHub, выполним следующую команду в терминале. Обратите внимание, что нужно обязательно изменить URI репозитория на свой.
Проект может иметь несколько удаленных репозиториев одновременно. Чтобы их различать, мы дадим им разные имена. Обычно главный репозиторий называется origin.
2. Отправка изменений на сервер
В зависимости от сервиса, который вы используете, вам может потребоваться аутентифицироваться, чтобы изменения отправились. Если все сделано правильно, то когда вы посмотрите в удаленный репозиторий при помощи браузера, вы увидите файл hello.txt
3. Клонирование репозитория
Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.
Новый локальный репозиторий создается автоматически с GitHub в качестве удаленного репозитория.
4. Запрос изменений с сервера
Если вы сделали изменения в вашем удаленном репозитории, другие пользователи могут скачать изменения при помощи команды pull.
Так как новых коммитов с тех пор, как мы склонировали себе проект, не было, никаких изменений доступных для скачивания нет.
Ветвление
Во время разработки новой функциональности считается хорошей практикой работать с копией оригинального проекта, которую называют веткой. Ветви имеют свою собственную историю и изолированные друг от друга изменения до тех пор, пока вы не решаете слить изменения вместе. Это происходит по набору причин:
1. Создание новой ветки
Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch
Это создаст новую ветку, пока что точную копию ветки master.
2. Переключение между ветками
Сейчас, если мы запустим branch, мы увидим две доступные опции:
master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.
3. Слияние веток
Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:
Изменения завершены, теперь мы можем переключиться обратно на ветку master.
Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).
Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.
Дополнительно
В последней части этого руководства мы расскажем о некоторых дополнительных трюках, которые могут вам помочь.
1. Отслеживание изменений, сделанных в коммитах
У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show [commit]
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
Мы сравнили первый коммит с последним, чтобы увидеть все изменения, которые были когда-либо сделаны. Обычно проще использовать git difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.
2. Возвращение файла к предыдущему состоянию
3. Исправление коммита
Если вы опечатались в комментарии или забыли добавить файл и заметили это сразу после того, как закоммитили изменения, вы легко можете это поправить при помощи commit —amend. Эта команда добавит все из последнего коммита в область подготовленных файлов и попытается сделать новый коммит. Это дает вам возможность поправить комментарий или добавить недостающие файлы в область подготовленных файлов.
Для более сложных исправлений, например, не в последнем коммите или если вы успели отправить изменения на сервер, нужно использовать revert. Эта команда создаст коммит, отменяющий изменения, совершенные в коммите с заданным идентификатором.
Самый последний коммит может быть доступен по алиасу HEAD:
Для остальных будем использовать идентификаторы:
При отмене старых коммитов нужно быть готовым к тому, что возникнут конфликты. Такое случается, если файл был изменен еще одним, более новым коммитом. И теперь git не может найти строчки, состояние которых нужно откатить, так как они больше не существуют.
4. Разрешение конфликтов при слиянии
Помимо сценария, описанного в предыдущем пункте, конфликты регулярно возникают при слиянии ветвей или при отправке чужого кода. Иногда конфликты исправляются автоматически, но обычно с этим приходится разбираться вручную — решать, какой код остается, а какой нужно удалить.
Давайте посмотрим на примеры, где мы попытаемся слить две ветки под названием john_branch и tim_branch. И Тим, и Джон правят один и тот же файл: функцию, которая отображает элементы массива.
Джон использует цикл:
Тим предпочитает forEach:
Они оба коммитят свой код в соответствующую ветку. Теперь, если они попытаются слить две ветки, они получат сообщение об ошибке:
Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
Когда все готово, нужно закоммитить изменения, чтобы закончить процесс:
Как вы можете заметить, процесс довольно утомительный и может быть очень сложным в больших проектах. Многие разработчики предпочитают использовать для разрешения конфликтов клиенты с графическим интерфейсом. (Для запуска нужно набрать git mergetool).
Вот хорошие примеры файлов, которые нужно игнорировать:
Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.
Заключение.
Вот и все! Наше руководство окончено. Мы очень старались собрать всю самую важную информацию и изложить ее как можно более сжато и кратко.
Git довольно сложен, и в нем есть еще много функций и трюков. Если вы хотите с ними познакомиться, вот некоторые ресурсы, которые мы рекомендуем:
