GitHub Workflow Tutorial PDF

GIT (1) GITHUB (II) WORKFLOW Jaroslav Grablevski Common Git workflows  Centralized Workflow  Feature Branching  Gitflow Workflow  Forking Workflow 2 Centralized Workflow  The centralized workflow treats a single repository (often the main...

GIT (1) GITHUB (II) WORKFLOW Jaroslav Grablevski Common Git workflows  Centralized Workflow  Feature Branching  Gitflow Workflow  Forking Workflow 2 Centralized Workflow  The centralized workflow treats a single repository (often the main branch) as the central authority, similar to traditional version control systems like SVN. Developers clone the repository, make changes locally, and push directly to the central repository, often without extensive branching. 3 Centralized Workflow 4 Centralized Workflow 5 Gitflow Workflow  Gitflow is a structured branching model with two main branches (main and develop) and supporting branches for features, releases, and hotfixes. Developers create feature branches from develop, merge them back after completion, and create release branches for finalizing versions and hotfix branches for urgent patches to production. 6 Gitflow Workflow 7 Branches ⬜ master (or main) - stores the currently released version of code and should match the code that is in production. ⬜ develop - stores a copy of the main branch with all additional changes that have been added since the last release. ⬜ feature - developers branch off of develop and create feature branches for any new features they are working on. There isn’t a single branch called feature unlike main and develop.  branch names will generally be named based on the change that is being made bug/StackOverflowFixInService. If you are using JIRA then you might see the JIRA issue number in the branch as well task/PRJ-1234-AddCardPage. ⬜ hotfix” - branches are used to quickly patch production releases. This is the only branch that should fork directly off of main/master. Forking Workflow  The forking workflow is common in open-source projects where contributors fork the central repository into their accounts, make changes in their forks, and submit pull requests to propose changes to the original repository. 9 Feature Branching  Feature branching creates a separate branch for each new feature or task. Developers work on these isolated branches, and once the feature is complete and reviewed, it is merged back into the main branch (or a development branch), allowing parallel development without affecting the stable codebase. 10 Paruošimieji darbai ⬜ Išsirinkite kas komandoje bus atsakingas už GitHub ⬜ Tas žmogus sukuria repozitoriją GitHub‘e, pakviečia kitus, apsaugo pagrindines šakas ⬜ Nepamirškite.gitignore failo: ADDING GITHUB COLLABORATORS ⬜ Pakvieskite savo komandos narius: 12 ADDING GITHUB COLLABORATORS  Kiti komandos nariai priima pakvietimus 13 Branch protection rule ⬜ Apsaugokite pagrindinę šaką (main/master): Branch protection rule ⬜ Pakeitimus į pagrindinę šaką galėsime įkelti tik per Pull request‘us ⬜ Nurodykite kiek žmonių turi patvirtinti Pull request‘ą GITHUB PULL REQUEST 16 Darbo eiga (pradžia) ⬜ Jei neturite repozitorijos kompiuteryje:  Jei turite: Darbo eiga (darbas su užduotimi) ⬜ Pradedant darbą (kai paimat užduotį iš Jira), sukuriate naują šaką. Tvarkingas šakos pavadinimas pagal susitarimą komandoje : Darbo eiga (darbas su užduotimi) ⬜ Dirbame šakoje ir saugome pakeitimus: Šakos sinchronizavimas su main ⬜ Prieš darant push, atnaujiname savo šaką (pritaikome naują kodą iš main šakos, jei ten toks yra). Galima naudoti merge: ⬜ Arba tiesiogai šakoje: Konfliktai ⬜ Sprendžiate konfliktus jei tokie yra: Rebase vietoj merge ⬜ Atnaujiname šaką su rebase (alternatyvus variantas merge, naudokite vieną iš jų!). Merge vs. rebase ⬜ Merge - esamos šakos suliejimas su nurodyta: Merge vs. rebase ⬜ Rebase - esamos šakos suliejimas su nurodyta, perrašant šakos (branch) įrašus (commit) taip, kad jie atrodytų, jog pradėti nuo kitos šakos paskutinio commit‘o. ⬜ Tai dažnai naudojama siekiant išlaikyti projektų istoriją tvarkingesnę ir aiškesnę, tačiau reikia būti atsargiems, nes keičiama įrašų istorija. Darbo eiga (darbas su užduotimi) ⬜ Push Feature Branch to Remote: Darbo eiga (pull request)  Create a Pull Request (PR)  Go to GitHub and create a Pull Request from your feature branch to the main branch. This is where your code will be reviewed. Darbo eiga (pull request)  Review and Approve PR  Have your PR reviewed by someone. Make any additional changes if needed and commit them. Darbo eiga (pull request)  Merge the PR  After review and approval, merge the PR into the development branch. Darbo eiga  Return to the Main Branch and Pull Changes Darbo eiga (delete)  Delete the Feature Branch (optional) Darbo eiga (toliau)  Naujai užduočiai kuriame naują šaką Papildomos, kartais naudingos komandos git stash Jei padarėte commit ne toje šakoje