📝 update CONTRIBUTING.md

This commit is contained in:
anyreso 2024-04-25 00:02:10 -04:00
parent 44367e916f
commit eb627cffd1

View file

@ -14,22 +14,37 @@ Include as much detail as possible, such as steps to reproduce the issue, expect
## Merge Requests and Releases ## Merge Requests and Releases
We highly recommend using [gitmoji](https://gitmoji.dev) for expressive and visually appealing commit messages, as it provides an easy way of identifying the purpose or intention of a commit simply by looking at the emojis used. When starting work on a new feature or bug fix, developers should always use the `develop` branch as their starting point.
Every [merge request (MR)][#create_merge_requests] must be merged into the `develop` branch before any release is made on the `main` branch. The `develop` branch contains the most recent and advanced codebase, as it serves as a staging area for upcoming features and fixes.
The `develop` branch serves as the staging area for upcoming features and fixes. Periodically, changes from `develop` are merged into the `main` branch to package releases.
When the `develop` branch is deemed stable and ready for release, it is merged into the `main` branch to create a new release.
This practice ensures that everyone remains updated on ongoing tasks, fostering transparency and encouraging collaboration. This practice ensures that everyone remains updated on ongoing tasks, fostering transparency and encouraging collaboration.
> All [merge requests (MR)][#create_merge_requests] must be merged into `develop` before any release is made on the `main` branch.
```mermaid
flowchart LR
subgraph Alice's Fork
A[Feature Branch] --> C((Merge Request))
end
subgraph Bob's Fork
B[Feature Branch] --> D((Merge Request))
end
subgraph open-fpsz
C -->|To Target Branch| E[develop]
D -->|To Target Branch| E[develop]
E -->|Merge into\nOnce Stable & Ready| G[main]
end
```
## Fork-based workflow ## Fork-based workflow
If you want to contribute changes without write access to the repository, you can still do so by forking. This is a simple way for anyone to contribute by creating your own copy of the project where you can make changes freely. If you want to contribute changes without write access to the repository, you can still do so by forking. This is a simple way for anyone to contribute by creating your own copy of the project where you can make changes freely.
1. First, you'll need to fork the repository. 1. First, you'll need to fork the repository.
2. Once you have a fork, clone it to your local machine. 2. Once you have a fork, clone it to your local machine and create a new branch from the `develop` branch.
3. Then, you can make changes just like you would if you were a member of the project. 3. Then, you can make changes just like you would if you were a member of the project.
4. After you've made your changes, you commit them locally and push these back to your fork on gitlab. 4. After you've made your changes, you commit them locally and push these back to your fork on gitlab.
5. Finally, you can [create a merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#when-you-work-in-a-fork) from your fork's branch to upstream's branch. 5. Finally, you can [create a merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#when-you-work-in-a-fork) from your fork's branch to upstream's branch.
@ -80,6 +95,8 @@ This naming convention helps to categorize branches and makes it easier to ident
# Git Quick Reference # Git Quick Reference
> We highly recommend using [gitmoji](https://gitmoji.dev) for expressive and visually appealing commit messages, as it provides an easy way of identifying the purpose or intention of a commit simply by looking at the emojis used.
1. Create a new branch for your changes: 1. Create a new branch for your changes:
```shell ```shell