Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly
Sign up
Appearance settings

Commit 54ccba6

Browse files
Merge pull request #5 from DevLoversTeam/develop
Develop
2 parents a9d04e7 + 3221cb3 commit 54ccba6

File tree

1 file changed

+275
-1
lines changed

1 file changed

+275
-1
lines changed

‎README.md‎

Lines changed: 275 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -579,7 +579,281 @@ Merge дозволяє безпечно інтегрувати паралель
579579
</details>
580580

581581
<details>
582-
<summary>21. ???</summary>
582+
<summary>21. Який Git workflow ви зазвичай використовуєте в роботі?</summary>
583+
584+
#### GIT
585+
586+
- Найчастіше використовую Git Flow / Feature Branch Workflow:
587+
588+
- `main` — завжди стабільна продакшн-версія.
589+
590+
- `develop` — інтеграційна гілка для нових фіч.
591+
592+
- для задач створюю окрему `feature`.
593+
594+
- після завершення — `pull request` → `code review` → `merge у develop`.
595+
596+
- перед релізом створюється `release`, після тестів — `merge у main` + тег.
597+
598+
- багфікси йдуть у `hotfix` від main.
599+
600+
Цей процес дисциплінує, дає прозорість і контроль над релізами.
601+
602+
</details>
603+
604+
<details>
605+
<summary>22. Опишіть кроки створення нової гілки та її злиття в main.</summary>
606+
607+
#### GIT
608+
609+
1. Переконуюсь, що локальний main оновлений:
610+
611+
```bash
612+
git checkout main
613+
git pull origin main
614+
```
615+
616+
2. Створюю нову гілку від main:
617+
618+
```bash
619+
git checkout -b feature/my-task
620+
```
621+
622+
3. Працюю, комічу зміни:
623+
624+
```bash
625+
git add .
626+
git commit -m "Implement feature X"
627+
```
628+
629+
4. Пушу гілку на remote:
630+
631+
```bash
632+
git push origin feature/my-task
633+
```
634+
635+
5. Відкриваю Pull Request → проходить code review → CI.
636+
637+
6. Мерджу в main (звичайно через squash або rebase, щоб історія була чистою).
638+
639+
7. Видаляю feature-гілку локально і на remote.
640+
641+
</details>
642+
643+
<details>
644+
<summary>23. Що таке merge conflict у Git і як його вирішують?</summary>
645+
646+
#### GIT
647+
648+
- Merge conflict виникає, коли дві гілки змінюють один і той самий рядок коду
649+
або файл у несумісний спосіб, і Git не може автоматично об’єднати зміни.
650+
651+
#### Рішення:
652+
653+
1. Виконати merge/rebase → Git покаже конфліктні файли.
654+
655+
2. Відкрити файл, знайти маркери <<<<<<<, =======, >>>>>>>.
656+
657+
3. Вибрати або об’єднати потрібні зміни вручну.
658+
659+
4. Позначити файл як вирішений:
660+
661+
```bash
662+
git add <file>
663+
```
664+
665+
5. Завершити merge/rebase комітом:
666+
667+
```bash
668+
git commit
669+
```
670+
671+
</details>
672+
673+
<details>
674+
<summary>24. Що таке fast-forward merge у Git?</summary>
675+
676+
#### GIT
677+
678+
- Fast-forward merge — це злиття, коли гілка-ціль (наприклад main) не має нових
679+
комітів після відгалуження feature-гілки. Тоді Git просто пересуває вказівник
680+
main на останній коміт feature-гілки без створення додаткового merge-коміту.
681+
682+
#### Приклад:
683+
684+
```bash
685+
git checkout main
686+
git merge feature/my-task --ff
687+
```
688+
689+
Це "чисте" злиття без зайвих комітів.
690+
691+
</details>
692+
693+
<details>
694+
<summary>25. Що таке three-way merge у Git?</summary>
695+
696+
#### GIT
697+
698+
- Three-way merge — це злиття, коли Git використовує три точки для об’єднання:
699+
700+
1. `common ancestor` (базовий коміт, від якого розійшлися гілки),
701+
702+
2. `HEAD` (останній коміт у цільовій гілці, наприклад main),
703+
704+
3. `branch tip` (останній коміт у зливаній гілці, наприклад feature).
705+
706+
Git порівнює зміни відносно спільного предка й створює новий merge-коміт, що має
707+
двох батьків.
708+
709+
Цей підхід застосовується, коли fast-forward неможливий (тобто в обох гілках є
710+
нові коміти).
711+
712+
</details>
713+
714+
<details>
715+
<summary>26. Які кроки виконати, щоб перебазувати (rebase) гілку в Git?</summary>
716+
717+
#### GIT
718+
719+
1. Перейти в свою гілку:
720+
721+
```bash
722+
git checkout feature/my-task
723+
```
724+
725+
2. Виконати rebase на актуальну main:
726+
727+
```bash
728+
git fetch origin git rebase origin/main
729+
```
730+
731+
3. Якщо є конфлікти — вирішити їх, додати файли:
732+
733+
```bash
734+
git add <file> git rebase --continue
735+
```
736+
737+
4. Коли все готово — оновити remote (з форсом, бо історія переписана):
738+
739+
```bash
740+
git push origin feature/my-task --force
741+
```
742+
743+
Rebase робить історію лінійною, на відміну від merge.
744+
745+
</details>
746+
747+
<details>
748+
<summary>27. Які плюси й мінуси rebase у порівнянні з merge?</summary>
749+
750+
#### GIT
751+
752+
✅ **Переваги rebase**
753+
754+
- Лінійна, чиста історія без merge-комітів.
755+
756+
- Зручніше читати git log, легше дебажити.
757+
758+
- Кожен коміт виглядає так, ніби зроблений поверх останнього main.
759+
760+
❌ **Недоліки rebase**
761+
762+
- Переписує історію (особливо небезпечно для спільних гілок).
763+
764+
- Потрібен --force push, що може зламати історію іншим.
765+
766+
- Вимагає більшої дисципліни в команді.
767+
768+
✅ **Переваги merge**
769+
770+
- Зберігає повну історію розробки, без переписування.
771+
772+
- Безпечний для командної роботи.
773+
774+
- Простий у використанні.
775+
776+
❌ **Недоліки merge**
777+
778+
- Брудніший git log з великою кількістю merge-комітів.
779+
780+
- Історію важче аналізувати.
781+
782+
Загалом: merge — безпечніше для команд, rebase — краще для чистої історії.
783+
784+
</details>
785+
786+
<details>
787+
<summary>28. Для чого використовуються теги в Git?</summary>
788+
789+
#### GIT
790+
791+
- Теги в Git — це фіксовані маркери на певні коміти, зазвичай для позначення
792+
релізів (v1.0, v2.1).
793+
794+
- `Lightweight tag` — просто вказівка на коміт, без додаткової інформації.
795+
796+
- `Annotated tag` — зберігає автора, дату, повідомлення і може бути підписаний
797+
GPG.
798+
799+
#### Теги зручні для:
800+
801+
- Відстеження версій у продакшн.
802+
803+
- Швидкого переходу на конкретний реліз:
804+
805+
```bash
806+
git checkout v1.0
807+
```
808+
809+
- CI/CD для автоматичного деплою.
810+
811+
</details>
812+
813+
<details>
814+
<summary>29. Як скасувати коміт, який вже запушено на remote?</summary>
815+
816+
#### GIT
817+
818+
1. Якщо потрібно повністю видалити коміт (історія переписується, небезпечно для
819+
інших):
820+
821+
```bash
822+
git reset --hard <коміт_до_потрібного>
823+
git push origin <гілка> --force
824+
```
825+
826+
2. Якщо потрібно зберегти історію, створивши "відкат" без перепису:
827+
828+
```bash
829+
git revert <hash_коміту>
830+
git push origin <гілка>
831+
```
832+
833+
- `reset --hard` + `force push` змінює історію (небезпечно для спільних гілок).
834+
835+
- `revert` створює новий коміт, що відміняє зміни — безпечніше для команд.
836+
837+
</details>
838+
839+
<details>
840+
<summary>30. Яке призначення головної гілки (main/master) у Git?</summary>
841+
842+
#### GIT
843+
844+
Головна гілка (main або раніше master) — це стабільна, завжди робоча версія
845+
проєкту, на яку орієнтуються всі інші гілки.
846+
847+
- Від неї створюють feature-, release-, hotfix-гілки.
848+
849+
- Вона слугує базою для релізів.
850+
851+
- Зазвичай на ній запускається CI/CD і деплой в продакшн.
852+
853+
</details>
854+
855+
<details>
856+
<summary>31. ???</summary>
583857

584858
#### GIT
585859

0 commit comments

Comments
(0)

AltStyle によって変換されたページ (->オリジナル) /