mirror of
https://github.com/wahyd4/gitlabhq.git
synced 2026-08-19 09:36:47 +10:00
74 lines
2.5 KiB
Plaintext
74 lines
2.5 KiB
Plaintext
= render layout: 'help/layout' do
|
|
%h3.page-title Workflow
|
|
|
|
%h4 Summary
|
|
|
|
%ol.help
|
|
%li
|
|
%p Clone project
|
|
.bash
|
|
%pre.dark
|
|
git clone git@example.com:project-name.git
|
|
|
|
%li
|
|
%p Create branch with your feature
|
|
.bash
|
|
%pre.dark
|
|
git checkout -b $feature_name
|
|
|
|
%li
|
|
%p Write code. Commit changes
|
|
.bash
|
|
%pre.dark
|
|
git commit -am "My feature is ready"
|
|
|
|
%li
|
|
%p Push your branch to GitLab
|
|
.bash
|
|
%pre.dark
|
|
git push origin $feature_name
|
|
|
|
%li
|
|
%p Review your code on Commits page
|
|
|
|
%li
|
|
%p Create a merge request
|
|
|
|
%li
|
|
%p Your team lead will review code & merge it to main branch
|
|
|
|
%h3 Authorization for Merge Requests
|
|
%p
|
|
There are two main ways to have a merge request flow with GitLab: working with protected branches in a single repository, or working with forks of an authoritative project.
|
|
|
|
%h4 Protected branch flow
|
|
%p
|
|
With the protected branch flow everybody works within the same GitLab project.
|
|
The project maintainers get Master access and the regular developers get Developer access.
|
|
The maintainers mark the authoritative branches as 'Protected'.
|
|
The developers push feature branches to the project and create merge requests to have their feature branches reviewed and merged into one of the protected branches.
|
|
Only users with Master access can merge changes into a protected branch.
|
|
|
|
%h5 Advantages
|
|
%ul
|
|
%li fewer projects means less clutter
|
|
%li developers need to consider only one remote repository
|
|
|
|
%h5 Disadvantages
|
|
%ul
|
|
%li manual setup of protected branch required for each new project
|
|
|
|
%h4 Forking workflow
|
|
%p
|
|
With the forking workflow the maintainers get Master access and the regular developers get Reporter access to the authoritative repository, which prohibits them from pushing any changes to it.
|
|
Developers create forks of the authoritative project and push their feature branches to their own forks.
|
|
To get their changes into master they need to create a merge request across forks.
|
|
|
|
%h5 Advantages
|
|
%ul
|
|
%li in an appropriately configured GitLab group, new projects automatically get the required access restrictions for regular developers: fewer manual steps to configure authorization for new projects
|
|
|
|
%h5 Disadvantages
|
|
%ul
|
|
%li all developers on the project need to keep their forks up to date, which requires more advanced Git skills (managing multiple remotes)
|