Подготовка
Авторизация идёт по ключу. Ключи брать у Asmodeus’a.
Прописать путь к ключу в /etc/ssh/ssh_config
Host abills.net.ua IdentityFile **Путь к ключу**
Указываем свои даные
# git config --global user.name *Имя разработчика* # git config --global user.mail *e-mail разработчика*
Клонирование репозитория
# cd /usr # git clone git@abills.net.ua:abills.git
*Если просит пароль для git, значит не подхватило ключ.
Создание ветки
Для примера, рассмотрим правку модуля Msgs. Переходим в dev:
# git checkout dev
Стягиваем обновления из dev
# git pull origin dev
Отделяем ветку
# git branch Msgs
Переходим в новую ветку
# git checkout Msgs
Можно одной командой
# git checkout -b Msgs
Рабочий процесс
Создаём новую ветку для задачи Msgs
# git checkout -b Msgs
В новой ветке:
Повторить нужное количество раз:
<эти действия>
Редактируем до достижения результата.
# edit some files\\ Фиксируем изменения:\\ # git commit -a -m ‘(описание изменений)’\\
</эти действия>
Заливаем в основной репозиторий в ветку Msgs
# git push origin Msgs
Залить готовые изменения (сделанные до подключения к git):
Перемещаем свою папку abills
Клонируем репозиторий
Отделяем ветку
Вносим свои изменения из копии
Фиксируем.
Внештатные ситуации:
Conflict Если несколько человек редактировали один файл, может возникнуть конфликт слияния.
После git pull и сообщения о возникновения конфликта
# vimdiff *путь к файлу*
ищем »»>HEAD
…..
===========
…..
««««<Msgs
Оставляем нужную часть, сохраняем
добавляем в index
# git add *путь к файлу*
Фиксируем,
Повторяем git pull
Отмена коммита
возврат к коммиту:
# git revert (hash-код комита)
возврат на 5 коммитов назад:
# git reset HEAD~5
Посмотреть историю коммитов для текущей ветки
# git log
Посмотреть, кто что правил в файле
# git blame <путь/к/файлу/имя файла>
Если во время работы над одной веткой, нужно перейти в другую, без фиксации изменений
“Прячем” изменения:
# git stash
Переходим в другую ветку:
# git checkout branch2
Редактируем:
# edit some files
Фиксируем:
# git commit -a -m ‘message’
Возвращаемся в первую ветку:
# git checkout branch1
Применяем спрятанные изменения:
# git stash pop
Git log варианты вывода
git log --graph --pretty=format:"%C(yellow)%h%Creset%C(blue)%d%Creset %C(white bold)%s%Creset %C(white dim)(by %an %ar)%Creset" --all
Обновление списка удалённых веток
# git remote update origin --prune
Алиасы
Вставить в ~/.gitconfig в секцию [alias]
[alias] st=status pl = pull ph = push b = branch ch = checkout df = diff hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short type = cat-file -t dump = cat-file -p
Процесс Code review для исполнителя
Подготовка кода к review
Убедиться, что функционал работает
Если это подключаемый функционал (через права или опцию в конфиге), убедиться что при выключении функционала система работает так же, как и до внесения изменений.
Просмотреть код и убрать всё, что использовалось при отладке (_bp, Dumper, импорт модулей с этими функциями)
Для алгоритмически сложных частей написать в комментариях, что именно делает код и почему использовалось именно это решение.
Залить код для проверки
Залить в отдельную ветку для review (
текущая_ветка
_review)Слить основную ветку (dev или ветку review'ера)
Поменять статус задачи на «На тестировании». Написать имя ветки в комментариях к задаче.
Уведомить ответственного за review гарантированным методом (личный контакт или по договорённости)
Обработать результат review
После получения ответа
Если задача перемещена в статус «Обратная связь»
Слить (merge) ветку
_review
в ветку задачи.В комментариях задачи просмотреть замечания (если есть)
Если задача перемещена в статус «Решена»
Ожидать решения ПМ по закрытию задачи.
Процесс Code review для проверяющего
Перейти на ветку для проверки задачи
Проверить выполнение
Проверить функционал
Проверить код (отметить подозрительные места, если есть). Где надо, выставить пометки
# TODO: comments
.Залить свою ветку в ветку
_review
Оставить замечания в комментариях к задаче.
Выставить нужный статус (
Решена
илиОбратная связь
)