Для удобной командной разработки в репозитории используется система управления задачами через GitHub Projects, Issues и отдельные рабочие ветки.
В репозитории используется доска задач (Projects) для отслеживания текущего состояния работ.
Открыть можно во вкладке:
Projects
Рекомендуется использовать представление:
My Tasks
Так как в нём отображаются только задачи, назначенные именно вам, как на рисунке ниже:
Также доступно представление:
All Tasks
где отображаются все задачи команды, как представлено на рисунке ниже:
Каждая задача оформляется как отдельный Issue.
Во вкладке:
Issues
можно увидеть:
- назначенные задачи
- описание задания
- необходимые файлы для реализации
- дополнительную информацию по задаче
Рисунок вкладки Issue:
Перед началом работы необходимо открыть свой Issue и ознакомиться с описанием:
Задачи перемещаются между статусами на доске Projects.
| Статус | Значение |
|---|---|
| To do | задача назначена вам |
| In Progress | задача находится в работе |
| Needs work | pull request отправлен на доработку |
| Review | pull request отправлен на проверку |
| Done | задача завершена |
Изменять статус можно:
- через правую панель в Issue
- напрямую на Project Board перетаскиванием карточки
Для каждой задачи создаётся отдельная ветка разработки через раздел Development в Issue.
Используются следующие типы веток:
working/<название_модуля>
bugfix/<название_модуля>
working/CW_PC
working/CW_ALU
bugfix/CW_REGFILE
Работа над задачей начинается с назначенного Issue в GitHub.
Перед началом работы необходимо:
- Открыть репозиторий на GitHub
- Перейти во вкладку
Issues - Открыть назначенную вам задачу
- Внимательно прочитать описание задачи
- Посмотреть, какие файлы нужно создать или изменить
Ветка создаётся не вручную локально, а через GitHub из самого Issue.
Для этого в правой панели Issue нужно найти блок:
Development
Далее создать ветку под задачу.
Используются такие названия веток:
working/<название_модуля>
bugfix/<название_модуля>
Примеры:
working/CW_PC
working/CW_ALU
bugfix/CW_REGFILE
После создания ветки GitHub покажет команды, которые нужно выполнить локально. Также не забудьте перенести Issue в состояние In Progress.
Перед переключением на новую ветку нужно обновить локальный main.
В обычной Git-консоли:
git checkout main
git pullПосле этого нужно выполнить команды, которые предложил GitHub в Issue.
Обычно они выглядят примерно так:
git fetch origin
git checkout working/CW_PCПосле этого вы окажетесь в своей рабочей ветке.
Проверить текущую ветку можно командой:
git branchАктивная ветка будет отмечена символом *.
После перехода на рабочую ветку нужно открыть Vivado.
На стартовом экране Vivado не нужно открывать старый проект вручную.
Сначала откройте Tcl Console.
Перейдите в папку репозитория:
cd <путь_к_репозиторию>Например:
cd D:/VivadoProjects/FPGA_CW_6semПосле этого создайте локальный Vivado-проект:
source scripts/create_project.tclСкрипт создаст проект в папке:
build/FPGA_CW_6sem/
Затем откройте созданный проект (возможно он откроется сам после создания):
open_project build/FPGA_CW_6sem/FPGA_CW_6sem.xprСкрипт create_project.tcl не нужно запускать после каждого изменения файла.
Его нужно запускать только в следующих случаях:
- после перехода на новую ветку
- если проект Vivado сломался или некорректно открывается
- и др. случаи
Во время обычной работы в своей ветке (когда вы уже сделали один раз create_project.tcl) достаточно просто открывать уже созданный проект:
build/FPGA_CW_6sem/FPGA_CW_6sem.xpr
После открытия проекта можно работать как обычно:
- редактировать HDL-модули
- создавать новые модули
- изменять testbench
- изменять constraints
- добавлять
.mem,.coe,.hexфайлы - запускать simulation
- запускать synthesis / implementation
Важно понимать структуру проекта:
files/ — файлы, которые хранятся в Git
build/ — локальный Vivado-проект, который НЕ коммитится
scripts/ — Tcl-скрипты для создания проекта и экспорта файлов
Git отслеживает изменения только в:
files/scripts/README.md.gitignoreLICENSE
Папка build/ в Git не попадает.
Если вы изменили файл через Vivado или ISE, он изменился внутри папки проекта (build/, build_ise/ и т.д.).
Перед commit нужно обязательно перенести изменённый файл обратно в папку files/.
Для этого в Tcl Console подключите скрипт экспорта:
source scripts/export_new_file.tclПосле этого станут доступны команды:
export_src
export_sim
export_constr
export_mem
export_mem_src
export_mem_sim
Если был изменён или создан исходный HDL-файл:
export_src <имя_файла>Пример:
export_src CW_ALU.vФайл будет перенесён в:
files/sources/
Если был изменён или создан testbench:
export_sim <имя_файла>Пример:
export_sim TB_CW_ALU.vФайл будет перенесён в:
files/simulations/
Если был изменён .xdc или .ucf файл:
export_constr <имя_файла>Пример:
export_constr Nexys-A7.xdcФайл будет перенесён в:
files/constraints/
Если был изменён или создан memory-файл (.mem, .coe, .hex):
export_mem <имя_файла>Примеры:
export_mem ROM.mem
export_mem program.coe
export_mem init.hexКоманда автоматически:
- ищет файл в
sources_1иsim_1 - определяет, является ли файл source или simulation
- экспортирует файл в нужную папку
Если memory-файл относится к исходным файлам проекта, он будет перенесён в:
files/sources/
Пример:
files/sources/ROM.mem
Если memory-файл относится к simulation/testbench, он будет перенесён в:
files/simulations/
Пример:
files/simulations/TB_ROM.mem
Если файл с одинаковым именем существует и в source, и в simulation, используйте явные команды:
export_mem_src <имя_файла>
export_mem_sim <имя_файла>Примеры:
export_mem_src ROM.mem
export_mem_sim ROM.memЕсли файл уже существует в files/, он будет заменён новой версией.
То есть команда:
export_src CW_ALU.vзаменит файл:
files/sources/CW_ALU.v
актуальной версией из Vivado-проекта.
Если export не сделать, Git не увидит ваши изменения, потому что папка build/ не коммитится.
После export нужно вернуться в обычную Git-консоль и выполнить:
git statusВ изменениях должны быть файлы из папки:
files/
Например:
modified: files/sources/CW_ALU.v
Если измененений не видно, то изменены только файлы внутри build/ и export не был выполнен.
Добавьте нужные файлы:
git add <file.v>Можно также добавить всё сразу:
git add .После этого снова проверьте:
git statusСоздайте commit с понятным сообщением:
git commit -m "Implement CW_ALU"Другие примеры:
git commit -m "Fix CW_REGFILE reset logic"
git commit -m "Add CW_PC module"
git commit -m "Update simulation for CW_SREG"После commit отправьте изменения:
git pushЕсли Git попросит указать upstream, выполните команду, которую он предложит.
Обычно она выглядит так:
git push --set-upstream origin working/CW_PCили коротко:
git push -u origin working/CW_PCПосле push откройте репозиторий на GitHub.
GitHub обычно сам предложит создать Pull Request для только что отправленной ветки.
Нужно:
- Нажать
Compare & pull request - Проверить, что base branch —
main - Проверить, что compare branch — ваша рабочая ветка
- Заполнить описание Pull Request
- Указать, какой Issue закрывает этот PR (также Development только в PR)
- Указать Assignees на себя, Reviewers на вашего проверяющего.
- Отправить Pull Request на проверку
После создания Pull Request задачу нужно перевести в статус:
Review
Это значит, что работа завершена и ожидает проверки.
Если ревьюер нашёл ошибки, задача может быть переведена в:
Needs work
Тогда нужно:
- Вернуться в свою ветку
- Исправить замечания
- Сделать export изменённых файлов
- Сделать новый commit
- Выполнить
git push
Pull Request обновится автоматически.
После успешной проверки Pull Request будет объединён с main.
После этого задача переводится в статус:
Done
git checkout main
git pull
git fetch origin
git checkout working/<название_ветки>В Vivado Tcl Console:
cd <путь_к_репозиторию>
source scripts/create_project.tcl
open_project build/FPGA_CW_6sem/FPGA_CW_6sem.xprПеред commit:
source scripts/export_new_file.tcl
export_src <файл.v>В Git-консоли:
git status
git add files
git commit -m "Update <описание>"
git push