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

Browse source
This commit is contained in:
anyreso 2025-02-07 21:39:34 -05:00
parent 35a48396a6
commit de5f58f307
1 changed files with 11 additions and 26 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

37
CONTRIBUTING.md
View file

@ -14,28 +14,21 @@ Include as much detail as possible, such as steps to reproduce the issue, expect
## Merge Requests and Releases
When starting work on a new feature or bug fix, developers should always use the `develop` branch as their starting point.
The `develop` branch contains the most recent and advanced codebase, as it serves as a staging area for upcoming features and fixes.
Periodically, changes from `develop` are merged into the `main` branch to package releases.
This practice keeps everyone informed about ongoing tasks, promotes transparency, fosters collaboration, and safeguards newcomers from oversights in the review process.
When starting work on a new feature or bug fix, developers should always use the `main` branch as their starting point.
> Learn how to [create a merge request when you work in a fork][#create_merge_requests_from_fork].
```mermaid
flowchart LR
subgraph Alice's Fork
A[feat/alice-branch] --> C((Merge Request))
A[alice-new-feature] --> C((Merge Request))
end
subgraph Bob's Fork
B[feat/bob-branch] --> D((Merge Request))
B[bob-useful-bugfix] --> 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]
C -->|To Target Branch| E[main]
D -->|To Target Branch| E[main]
end
```
@ -44,14 +37,14 @@ flowchart LR
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 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.
2. Once you have a fork, clone it to your local machine and create a new branch.
3. Then, you can make few changes or even fix something.
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 `develop` 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 `main` branch.
> We encourage you to [allow commits from upstream members](https://docs.gitlab.com/ee/user/project/merge_requests/allow_collaboration.html#allow-commits-from-upstream-members) so that they can [push to the fork as the upstream member](https://docs.gitlab.com/ee/user/project/merge_requests/allow_collaboration.html#push-to-the-fork-as-the-upstream-member) in order for you to reach out for help.
The merge request notifies project maintainers that you've made changes and allows them to review your code and potentially merge it into the `develop` branch.
The merge request notifies project maintainers that you've made changes and allows them to review your code and potentially merge it into the `main` branch.
When your branch is merged, you may want to [update your fork](https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#update-your-fork) to be synced with upstream.
@ -61,7 +54,7 @@ Access to our [gitlab repository][#repo_url] is essential for collaborative deve
1. **Contribution**: Get involved in the project by contributing code, reporting issues, or participating in discussions on our [discord](https://discord.gg/tdmV3MxCn5) or [gitlab repository][#repo_url].
2. **Familiarization**: Read about development guidelines, coding style, conventions. Understanding these aspects will help you make meaningful contributions to our codebase.
3. **Request**: Upon a single merge request merged in `develop`, anyone can request to become a member, reach out to other members for access.
3. **Request**: Upon a single merge request merged in `main`, anyone can request to become a member, reach out to other members for access.
4. **Review**: We will assess factors such as the quality of your contributions, adherence to our guidelines and alignment with our project's vision.
5. **Access**: Upon approval, a membership will be granted to our [gitlab repository][#repo_url], allowing you to directly contribute, review changes and collaborate with others.
@ -87,20 +80,12 @@ For consistency across the source code, we *must* follow the [Godot Engine Style
> third-party game assets for a character, it makes more sense to include them
> within the same folder as the character scenes and scripts.
## Branch Naming Convention
When working on a new *feature*, prefix the branch name with `feat/`. For *bug fixes*, use the prefix `fix/`.
This naming convention helps to categorize branches and makes it easier to identify their purpose at a glance.
# 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
git checkout -b feat/my-branch
git checkout -b my-branch
```
2. Make your changes, stage then and commit: