Я унаследовал несколько странный репозиторий Git, который структурирован следующим образом:
Some Client - Programme/
├── ClientName.Thing1/
│ ├── ClientName.Thing1.sln
│ └── ClientName.Thing1.ProjectX/
│ ├── ClientName.Thing1.ProjectX.csproj
│ ├── file1.cs
│ └── file2.cs
└── ClientName.Thing2/
├── ClientName.Thing2.sln
├── ClientName.Thing2.ProjectY/
│ ├── ClientName.Thing2.ProjectY.csproj
│ ├── file3.cs
│ └── file4.cs
└── ClientName.Thing2.ProjectZ/
├── ClientName.Thing2.ProjectZ.csproj
├── file5.cs
└── file6.cs
По сути, у меня есть один репо, который содержит кучу папок; ClientName.Thing1, ClientName.Thing2, etc.. и весь код существует ниже этих папок верхнего уровня ..
Рабочий процесс, кажется, Person-A работает на ClientName.Thing2, а Person-B работает на ClientName.Thing1 одновременно, независимо ... оба могут быть открыты в Visual Studio с помощью файла * .sln.
Однако это означает, что, хотя они оба работают в разных областях ... они могут "перекрестно опылять", поскольку все это происходит из одной и той же ветви master, и технически Персона-А, даже если они не предназначены, могут редактировать что-то в «области» работы, на которую смотрит Person-B ..
Хотя это не самая большая проблема, самая большая проблема на самом деле - выпускать вещи и, в частности, получать сборку того аспекта, который вы хотите выпустить. На самом деле нет скомпилированного кода (python, sql и т. Д.), И поэтому можно «обойтись» простым подключением к репо в CICD-конвейере и развертыванием материала… без сборки, что, на мой взгляд, немного раздражает… ... это означает, что вы не можете гарантировать, что вы всегда развертываете одно и то же в каждой среде.
Итак, к вопросу!
Есть ли способ, что, если Person-A фиксирует некоторые изменения в что-нибудь , которое находится в папке ClientName.Thing2, для него, чтобы вызвать сборку только для определенного определения сборки ??
Прямо сейчас ... я вижу только способ запуска коммита в репо в целом, который будет супер супер шумным!