GITHUB

Question 1

Што претставува Source (Version) Control?

Answer 1

Source control е витална компонента од животниот циклус за развој на софтвер. Овозможува:

Пратење на промени, преглед на историја на промени, интеграција со околини за развој на софтвер, автоматизација, итн.

Question 2

Познати Source Control Management системи?

Answer 2

Git, Subversion, Mercurial, Perforce, CVS..

Question 3

Точно или грешно:

Постојат локални, централни и дистрибуирани VCS системи.

Answer 3

Точно.

Question 4

Што е git и што овозможува?

Answer 4

Git e version control system кој се корист за пратење на промени во изворниот код за време на развој на софтвер.

Овозможува:

Колаборативна работа на повеќе девелопери, работа на различни гранки, навраќање на претходни верзии, итн.

Question 5

Кои се трите главни состојби во кои можат да бидат фајловите на git?

Answer 5

Modified, staged и commited.

Question 6

Кога го обележуваме променетиот фајл и ја спремаме неговата моментална верзија за следниот commit, од која во која состојба преминува фајлот?

Answer 6

Преминува од modified во staged.

Question 7

Што претставува состојбата commited?

Answer 7

Податоците се безбедно зачувани во нашата локална база на податоци

Question 8

Со која команда се иницијализира репозиториум во веќепостоечка дадотека?

Answer 8

git init

Question 9

За што се користи git add?

Answer 9

За променетите документи да преминат од modified во staged

Question 10

Со која команда се прави commit?

Answer 10

git commit

Question 11

Како да провериме дали состојбата на гранката во репозиториумот е во тек со локалната база?

Answer 11

git status

Question 12

Животен циклус на датотеките?

Answer 12

Untracked -> (add file) -> staged
Unmodified -> (edit) -> modified -> (stage) -> staged
Staged -> (commit) ->unmodified
Unmodified -> (removed) -> untracked

Question 13

Со која команда се проверува краток статус на гранка?

Answer 13

git status -s

Question 14

Која наставка ја има датотеката која кажува какви датотеки да не се прикачуваат на репозиториумот?

Answer 14

.gitignore

Question 15

Доколку сакаме да корегираме скорашен commit која команда се користи?

Answer 15

git commit –amend

Question 16

За што се користи git reset HEAD <file>?</file>

Answer 16

За да се тргне датотека од staged состојба

Question 17

Доколку сакаме да вратиме верзија на конкретна датотека кон верзијата од последниот комит, која команда се користи?

Answer 17

git checkout – <file>
или git restore <file></file></file>

Question 18

Разлика помеѓу:
git checkout – <file>
и
git reset HEAD <file></file></file>

Answer 18

Со git checkout датотеката се враќа во unmodifed верзија, поради тоа што се зема верзијата на датотеката од последниот commit.

Додека, со reset датотеката останува иста на локалната машина, но само се враќа од staged состојба во modifed. Се користи кога сакаме да исклучиме некоја датотека од следниот commit.

Question 19

Како ги чува git податоците?

Answer 19

Како серии на snapshots.

Question 20

Што содржи commit објектот?

Answer 20

Commit објектот содржи:
Покажувач кон snapshot на содржината која е staged.
Име и мејл на авторот.
Пораката на комитот.
Покажувачи кон родителите на комитите кои се направени директно пред моменталниот.

Question 21

Што е гранка?

Answer 21

Гранка во git е покажувач кон некој комит.

Question 22

Како git знае на која гранка момоментално работиме?

Answer 22

Постои специјален покажувач: HEAD, кој покажува кон гранката (покажувач) на која работиме.

Question 23

Како се прават нови гранки на git?

Answer 23

git checkout -b <newbranchname>
git switch -c <newbranchname></newbranchname></newbranchname>

Question 24

Кога се прави merge, што означува фразата fast-forward?

Answer 24

Snapshot-от на новиот branch е директно поврзан со другиот, па оној branch на кој ги спојуваме промените само се поместува на snapshot-от до него.

Question 25

Доколку имаме конфликт после обид за спојување на две гранки, дали после корекцијата автоматски ќе се спојат гранките?

Answer 25

Откако рачно ќе ги корегираме конфликтите, потребно е да се направи git commit за да се заврши спојувањето на гранките.

Question 26

GitLab Flow

Answer 26

Првиот дел на овој workflow е планирање. Опфаќа неколку делови: проблеми, merge requests, epics, milestones, iterations, release, etc.

Во issues се дефинираат проблемите или нови работи во апликацијата. За проблемите се пишува опис.

Во merge requests се развиваат решенијата. Можат да се креираат самостојно или директно од некој issue. Доколку се merge-не поврзаниот issue автоматски се затвора.

Milestones се користат за тимовите да си дефинираат цели. Се групираат и организираат issues со merge requests. Обично служат за пратење на напредок на проектот и може да се поврзат со конкретен release.

По решавање на проблеми и завршување на merge requests со pipelines промените се прикачуваат соодветно…

УШТЕ ИМА!

Question 27

GitFlow

Answer 27

Централниот репозиториум има две гранки: master и develop. Во master гранката секогаш треба да има код спремен за продукција.

Feature гранките: може да се разгрануваат од master гранката, но мора да се спојуваат со develop.

Се прави нова гранка.
Се менува гранката.
Се префрламе на develop гранката.
Се спојуваат новата гранка со develop.
Од develop или master гранката се прави release гранка.
Се спојува release со master и develop.

Question 28

GitHub Flow

Answer 28

○ Fork the project.
○ Create a topic branch from master.
○ Make some commits to improve the project.
○ Push this branch to your GitHub project.
○ Open a Pull Request on GitHub.
○ Discuss, and optionally continue committing.
○ The project owner merges or closes the Pull Request.
○ Sync the updated master back to your fork.