From de5f58f30774ce2b5212b991f275ff1296f7ad04 Mon Sep 17 00:00:00 2001 From: anyreso Date: Fri, 7 Feb 2025 21:39:34 -0500 Subject: [PATCH] =?UTF-8?q?=F0=9F=93=9D=20update=20CONTRIBUTING?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- CONTRIBUTING.md | 37 +++++++++++-------------------------- 1 file changed, 11 insertions(+), 26 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2615420..d1f609c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -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: