... | ... | @@ -106,13 +106,17 @@ As a general rule, do not commit to the master branch of the project when you're |
|
|
|
|
|
As you are working, commit your status to your local repository on your computer, and feel free to push this new branch to the repository as well. In fact, it is strongly encouraged. Even if your code is not working correctly yet, is incomplete, or parts of it are either temporary patchwork or 'sphagetti code', it doesn't hurt to let others see where you're at. Feel free to comment "temporary" or something to that effect in parts of your code you intend to replace.
|
|
|
|
|
|
Once you feel your branch is complete, and what you wanted to add to the master branch is implemented, make sure the latest branch is pushed to main server and check it's here on the GitLab server.
|
|
|
Any time you're ready with any amount of progress it's time to make a Merge Request. You should make Merge Requests even when you aren't "done" yet, as it lets people see the logic behind your work as you're developing, and adapt to it. It's all with following the principle of 'Continuous Integration'. That being said, try to make sure your branches do not break the rest of the project when you submit your request.
|
|
|
|
|
|
To actually make the Merge Request simply make sure the latest branch is pushed to main server and check it's here on the GitLab server.
|
|
|
If it's here, navigate to the Merge Requests tab on the left, and you should see at least one button labelled "New merge request" in the upper right.
|
|
|
|
|
|
Clicking that, you'll be taken to a screen, where you can select your branch as a source, and target the branch from which you originally split it for merging. (This will usually be the master branch, but if you were making adjustments to another branch, be sure to select that, unless it was already merged into something else, in which case select that and so on.)
|
|
|
|
|
|
Finally, after the merge request was created, the whole team will see a notification about it. Some of us will go over it, check it for any issues and note them if there are any, or otherwise give our approval. Once it's been checked and no issues were found, the merge request will be approved, and your additions will be added to the original branch!
|
|
|
|
|
|
As a side note, the actual process of reviewing merge requests is referred to as Triaging (See below).
|
|
|
|
|
|
See Peace of Mind section in case you're worried about merging.
|
|
|
|
|
|
[:airplane: Would you like to know more?](https://docs.gitlab.com/ee/user/project/merge_requests/)
|
... | ... | @@ -120,7 +124,11 @@ See Peace of Mind section in case you're worried about merging. |
|
|
TL;DR:
|
|
|
- Don't work on master branch, pull it, then create your own and tweak that.
|
|
|
- Commit and push your work often so others can see and think ahead based on your work.
|
|
|
- Submit a merge request when you feel you're ready, and wait for it to be checked and approved.
|
|
|
- Submit a merge request as often as you can, as long as your changes (to the best of your knowledge) don't break the rest of the project, and wait for it to be checked and approved.
|
|
|
|
|
|
## Triaging
|
|
|
|
|
|
TODO
|
|
|
|
|
|
|
|
|
# 5. Notes for Peace of Mind
|
... | ... | |