Памятка: Типичные операции с репозитарием
На данной странице описан типичный цикл разарботки. Подробней смотри тут. Создание новой ветки; Создание комитов (фиксайи изменений); Передача новой ветки на удаленный сервер; Слияние новой ветки с основной веткой.
Подготовка (создание ветки)
Прежде чем начинать править/добавлять/удалять файлы нужно создать себе ветку. Имя ветки должно отражать характер изменения. Иногда бывает сложно придумать название. Поскольку имя ветки может содержать слеши, предлагается использовать группировку: wip/foo — Works in progress; Основная ветка, над которой ведется работа в данный момент. feat/foo — Добавление новых функций или возможностей. fix/foo — Фиксы найденных ошибок и багов. test/foo — Прочие ветки, создающиеся просто чтобы поэкспериментировать.
Первая часть — до слеша, показывает тип ветки. Вторая часть (в данном случае foo) содержит какое-то запоминающееся имя.
Например: Если я хочу начать работу над 3ей версией sb.py, то я создам ветку «wip/sb03». Если я просто хочу добавить какаю-то мелкую фичу, то я создам ветку «feat/my_feature». Если мне встретился segfault в модуле derp и я знаю как это исправить, то я создам ветку «fix/derp_segfault». Или можно сначала создать issue где подробно описать ошибку, а имя исправляющей ветки будет «fix/issueX» где X номер соответствующего issue. Если я хочу просто что-то протестировать, то я создам себе ветку например «test/sb_derp».
Вообще название ветки какой-то особой роли не играет, просто оно должно быть удобным для набора и запоминающимся.
Ветка — это что-то вроде копии кода на флешке. Прежде чем копировать следует убедиться, что вы берете именно последнюю версию. Перед последним клонированием репозитария могло пройти много времени, с тех пор код в основной ветке мог измениться. Переходим в ветку devel и обновляемся.
git checkout devel
git pull
Находясь в devel создаем новую локальную ветку и переходим в неё:
git checkout -b <имя_ветки>
Проверить в какой ветке вы в данный момент находитесь можно так:
$ git branch
devel
fix/6
* test/hw_moveit_cmds
Локальную ветку всегда можно удалить при помощи команды:
git branch -d <имя_ветки>
Вносим изменения и комитим
Теперь наконец-то можно править или добавлять код, любым удобным образом, после чего закомитить (запомнить) изменения.
Каждая ветка может содержать в себе несколько комитов, а в каждом комите могут быть изменены/добавлены/удалены несколько файлов. Также каждый комит имеет свой краткий комментарий, который будет виден в репозитарии.
После внесения нужных изменений можно проверить «заметил» ли это git.
$ git status
On branch test/hw_moveit_cmds
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: file1.cpp
modified: dir2/file2.cpp
Untracked files:
(use "git add <file>..." to include in what will be committed)
added.txt
no changes added to commit (use "git add" and/or "git commit -a")
Git видит, что два файла изменились и один добавился.
Если все правильно то надо добаить изменения во временный буфер. Добавить все файлы:
git add .
Или добавляем каждый файл по отдельности:
git add file1.cpp
git add dir2/file2.cpp
До фиксации изменений желательно проверить, что именно добавилось во временный буфер:
$ git status
В ветке test/hw_moveit_cmds
Your branch is up-to-date with 'origin/solutionX'.
Изменения для закрепления:
(используйте "git reset HEAD <file>..." чтобы убрать из буфера)
modified: file1.cpp
modified: dir2/file2.cpp
Changes not staged for commit:
(используйте "git add <file>..." чтобы обновить данные для закрепления)
(используйте "git checkout -- <file>..." чтобы отменить изменения в рабочей директории)
modified: this/file/is/not/added.cpp
Тут два файла было добавлено, а один имеет изменения, но не добавлен в буфер. Можно либо тоже добавить его, либо откатить до прошлой версии, либо просто так и оставить, добавить его в следующем комите например.
Теперь локально комитим изменения, присваивая комментарий:
git commit -m 'New awesome feature'
Заливаем изменения в удаленный репозитарий:
git push -u origin <имя_ветки>
После этого новая ветка должна появиться на gitlab на вкладке «Branches».
Использование Pull request
Если вы закончили работу над веткой и хотите перенести изменения в основную ветку, то надо создать «Pull request» — запрос на перенос изменений в ветку devel. Для этого переходим в раздел «Branches» на gitlab и нажимаем кнопку «Merge Request».
Некоторые ветки можно сливать самостоятельно без Pull request'а.
Чтобы добавить какой-то код в другую ветку (например, пофикшенный баг распространить по веткам), надо зайти в неё (checkout fix/bug1) и сделать merge с веткой, откуда код добавляется, причём рекомендуется делать не фаст форвард слияние, чтобы в истории было видно, где оно было, т.е.:
merge --no-ff feat/leg1_moveit
Использование issue
Issues (тикеты, публикации, запросы) нужны для оповещения остальных членов команды о том, что существует какая-то проблема или задача, которую надо решить. Т.е. это указание на отсутствующий функционал либо на наличие ошибки. Тикет может быть закрыт при помощи «pull request», для этого в комментарии при создании комита надо указать номер соответствующего тикета.
git commit -m 'Solution for issue #6'
При слиянии веток соответствующий issue закроется автоматически.