GIT
git init # создание репозитория в рабочем каталоге
git clone # клонирование репозитория
git clone http://mygit/myproject.git # пример клонирования.
git fetch <название сервера> <название ветки> # загрузка изменений
git pull <название сервера> <название ветки> # загрузка и автоматическое слияние изменений
git branch <название ветки> # создание ветки
git checkout <название ветки> # переключение рабочей ветки
git checkout -b <название ветки> # создание ветки и переключение на неё.
git add . # индексирование всех изменений в рабочем каталоге.
git commit -m <текст сообщения> # выполнение коммита.
git push <название сервера> <название ветки> # загрузить изменения
git push --tags <название сервера> <название ветки> # загрузить изменения
git tag -a <название тэга> -m <сообщение к тэгу> # создание аннотируемого тэга к коммиту.
git merge <название целевой ветки> # выполнения слияния веток
git status # проверка текущего состояния репозитория git
git sumodule add <URL> <FOLDER> # Добавление сабмодуля.
GITFLOW
- Master Branch - главная ветка. Все изменения на эту ветку должны быть влиты только после того, как они были протестированы, отревьюлены и готовы для релиза.
- Develop Branch - ветка разработчиков. Это основной источник для всех изменений кода, которые проходят проверку и объединение в Master.
- Feature Branches - ветки функций. От вышеперечисленных веток, с целью добавления новой функциональности в приложение или исправления ошибок разработчики могут создавать Feature ветки. В feature ветках, происходит ключевая часть работы по разработке новой фичи.
- Release Branches - ветки выпусков. Когда все изменения готовы и нужно запустить продакшен-версию, команды создают release ветки для подготовки к независимому мерджу изменений со второстепенной ветки Develop в ветку Production.
- Hotfix Branches - ветки исправления ошибок. Используются командами, чтобы исправить проблему в Production срочно и необходимо сделать исправление вне сроков следующего релиза.
Применение этой методологии может помочь избежать состояния блокировки ветвей, гарантировать скорость доставки и улучить качество кода.
Резюме по вопросу использования отдельного проекта2 в качестве модуля основного проекта1, в случае, когда оба проекта загружены в репозиторий2 и репозиторий1 соответственно:
1. Добавить репозиторий2 как подмодуль: --> git submodule add https://github.com/username/repository2.git
2. Загрузить содержимое подмодуля в директорию repository2: --> git submodule update --init --recursive
3. Обновить подмодуль: --> git submodule update --remote
Чтобы не было путаницы, можно использовать загружаемые подмодули в качестве пакета, тогда у файла .py будет создаваться своя директория.
1. Переход в директорию подмодуля;
2. Проверка ветки: --> git branch -a
3. Переход в ветку: --> git checkout ветка 4. Загрузка обновлений: --> git pull