1. Организация на Git Flow
————————–
### Основни бранчове:
* **master**: Стабилна версия, готова за release.
* **development**: Основен бранч за разработка.
* **stage**: Този бранч е “On hold”. В бъдеще може да бъде използван за тестова среда.
### Работни бранчове:
* **feature/{номер_на_задача}-{име_на_задача}**: За нови функционалности.
* **bugfix/{номер_на_задача}-{име_на_бъг}**: За оправяне на бъгове.
* **hotfix/{номер_на_проблем}-{име_на_критичен_бъг}**: За критични бъгове, които блокират системата.
* **installers/{име_на_инсталатор}-{дата}**: За версии на инсталери. Тук ще е добре да пазим и предходна версия или да знаем точна дата на качване на бранча, т.е. бранча може да е с датата, като може да пазим текущата и предходната версия на бранча.. Пример:
* `spain_2025_01_31`
* `spain_2025_03_22`
* * *
2. Работен процес
—————–
### 2.1. Нов User Story или Bugfix
1. **Създаване на нов бранч от **`development`**:
git checkout development
git pull origin development
git checkout -b feature/1234-New-Feature-Name
**През VS:**
* Git меню → Manage branches → Checkout `development` → Pull → New local branch from
* Долу вдясно: `New Branch`
* **През Azure Boards**: Върху задачата → “Create a branch”
2. **Работа по задачата** (комитване с номер на задачата):
git add .
git commit -m “#1234: Добавен нов модул”
3. **Актуализиране с `development`:
git checkout development
git pull origin development
git checkout feature/1234-New-Feature-Name
git merge development
4. **Създаване на Pull Request към **“ (в Azure DevOps).
5. **Ако не се използва PR**, пушване и merge към `development`:
git push origin feature/1234-New-Feature-Name
git checkout development
git merge feature/1234-New-Feature-Name
git push origin development
### 2.2. Големи задачи (нови големи фийчъри заразработване)
* Използвайте отделен feature бранч, който периодично се обновява от `development`.
* След завършване:
1. Вземете последните промени от `development`.
2. Пушнете финалните промени и направете merge.
* * *
3. Релийз на нова версия
————————
1. **Сливане на **`development`** в **`master`**:
git checkout master
git merge development
git push origin master
2. **Създаване на нов в папка **`installers/`** бранч**:
git checkout master
git checkout -b installers/spain_2025_03_22
git push origin installers/spain_2025_03_22
* * *
4. Hotfix процес
—————-
1. Създаване на бранч от **`master`**:
git checkout master
git checkout -b hotfix/9101-Critical-Bug
2. След оправянето, веднага се пушва към **`development`**, ако всичко е ок, се правят промени и на **`master`** и се качва версия с хотфикс на продукшън
* * *
5. Rebase или Merge?
——————–
* **Merge**: Запазва историята с “merge commit”. Подходящо за завършени задачи.
* **Rebase**: Подрежда историята линейно. Подходящо за актуализиране на текущи бранчове.
**Препоръки:**
* Използвайте **Merge** за сливане на завършени задачи.
* Използвайте **Rebase** за актуализиране на работен бранч.
Пример за **Rebase**:
git checkout feature/1234-New-Feature-Name
git fetch origin
git rebase origin/development
* * *
6. Диаграми
———–
1. Организация на Git Flow
--------------------------
### Основни бранчове:
* **master**: Стабилна версия, готова за release.
* **development**: Основен бранч за разработка.
* **stage**: Този бранч е "On hold". В бъдеще може да бъде използван за тестова среда.
### Работни бранчове:
* **feature/{номер_на_задача}-{име_на_задача}**: За нови функционалности.
* **bugfix/{номер_на_задача}-{име_на_бъг}**: За оправяне на бъгове.
* **hotfix/{номер_на_проблем}-{име_на_критичен_бъг}**: За критични бъгове, които блокират системата.
* **installers/{име_на_инсталатор}-{дата}**: За версии на инсталери. Тук ще е добре да пазим и предходна версия или да знаем точна дата на качване на бранча, т.е. бранча може да е с датата, като може да пазим текущата и предходната версия на бранча.. Пример:
* `spain_2025_01_31`
* `spain_2025_03_22`
* * *
2. Работен процес
-----------------
### 2.1. Нов User Story или Bugfix
1. **Създаване на нов бранч от **`development`**:
git checkout development
git pull origin development
git checkout -b feature/1234-New-Feature-Name
**През VS:**
* Git меню → Manage branches → Checkout `development` → Pull → New local branch from
* Долу вдясно: `New Branch`
* **През Azure Boards**: Върху задачата → "Create a branch"
2. **Работа по задачата** (комитване с номер на задачата):
git add .
git commit -m "#1234: Добавен нов модул"
3. **Актуализиране с `development`:
git checkout development
git pull origin development
git checkout feature/1234-New-Feature-Name
git merge development
4. **Създаване на Pull Request към **`` (в Azure DevOps).
5. **Ако не се използва PR**, пушване и merge към `development`:
git push origin feature/1234-New-Feature-Name
git checkout development
git merge feature/1234-New-Feature-Name
git push origin development
### 2.2. Големи задачи (нови големи фийчъри заразработване)
* Използвайте отделен feature бранч, който периодично се обновява от `development`.
* След завършване:
1. Вземете последните промени от `development`.
2. Пушнете финалните промени и направете merge.
* * *
3. Релийз на нова версия
------------------------
1. **Сливане на **`development`** в **`master`**:
git checkout master
git merge development
git push origin master
2. **Създаване на нов в папка **`installers/`** бранч**:
git checkout master
git checkout -b installers/spain_2025_03_22
git push origin installers/spain_2025_03_22
* * *
4. Hotfix процес
----------------
1. Създаване на бранч от **`master`**:
git checkout master
git checkout -b hotfix/9101-Critical-Bug
2. След оправянето, веднага се пушва към **`development`**, ако всичко е ок, се правят промени и на **`master`** и се качва версия с хотфикс на продукшън
* * *
5. Rebase или Merge?
--------------------
* **Merge**: Запазва историята с "merge commit". Подходящо за завършени задачи.
* **Rebase**: Подрежда историята линейно. Подходящо за актуализиране на текущи бранчове.
**Препоръки:**
* Използвайте **Merge** за сливане на завършени задачи.
* Използвайте **Rebase** за актуализиране на работен бранч.
Пример за **Rebase**:
git checkout feature/1234-New-Feature-Name
git fetch origin
git rebase origin/development
* * *
6. Диаграми
-----------
