openfpsz/open-fpsz
1
0
Fork 0
mirror of https://gitlab.com/open-fpsz/open-fpsz.git synced 2026-01-19 19:44:46 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

📝 update CONTRIBUTING.md

Browse source
This commit is contained in:
anyreso 2024-04-25 00:02:10 -04:00
parent 44367e916f
commit eb627cffd1
1 changed files with 23 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

29
CONTRIBUTING.md
View file

@ -14,22 +14,37 @@ Include as much detail as possible, such as steps to reproduce the issue, expect
## 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.
When the `develop` branch is deemed stable and ready for release, it is merged into the `main` branch to create a new release.
Periodically, changes from `develop` are merged into the `main` branch to package releases.
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
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.
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.
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.
@ -80,6 +95,8 @@ This naming convention helps to categorize branches and makes it easier to ident
# 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:
```shell