|
| 1 | +<!-- TODO: Create new screen shots for this project --> |
| 2 | +# Branching |
| 3 | + |
| 4 | +## The branching strategy |
| 5 | + |
| 6 | +The branching strategy looks like this: |
| 7 | + |
| 8 | +The short description of the branching strategy is as follows. The feature branches are a category of branches that branch out of the `develop` branch. A person branches out from develop, works on a given feature on their branch and when the feature is ready they submit a Pull Request to merge again into the develop branch. After the review process is finished the commits from the branch should be squashed and then merged into `develop` (GitHubs WebUI provides that). Therefore each commit that lands on the `develop` branch is an addition of a feature, documentation etc.. When an arbitrary set of new features is completed and could be deemed as a new release (release cycle should follow the [semver](https://semver.org/) convention) it should be merged into `main` (of course it should also follow the process of a Pull Request and reviews) when it is merged into `main` additional testing, validation etc. should be done as this is now a release candidate. If the state of the code is deemed safe and proper it should be released as a new version of the software. This should be done by tagging which marks a given commit a release candidate which should automatically trigger a series of CI/CD checks and if they succeed the software package will be finally released. |
| 9 | + |
| 10 | + |
| 11 | + |
| 12 | +## Creating a task |
| 13 | + |
| 14 | +TL;DR |
| 15 | + |
| 16 | +If you want to work on something create an issue for that. |
| 17 | + |
| 18 | +1. Fill out the name for the issue |
| 19 | +2. Provide a description for the task and what are your plans etc. |
| 20 | +3. If you know you will be working on that task assign yourself |
| 21 | +4. Add applicable labels to the task, e.g. if you are solving a bug then add `Bug`, if adding a new functionality add `Enhancement` etc. |
| 22 | +5. Assign the task to the `rust-pip` project |
| 23 | +6. If applicable assign the task to a given milestone |
| 24 | +7. Submit the issue/task |
| 25 | + |
| 26 | + |
| 27 | + |
| 28 | +## Creating a branch and using it |
| 29 | + |
| 30 | +Then when you have created an issue for you task click the `Create new branch` in the lower right corner: |
| 31 | + |
| 32 | + |
| 33 | + |
| 34 | +Click on the `Change branch source`, then: |
| 35 | + |
| 36 | +1. Make sure that the actual branch name is concise and fairly short |
| 37 | +2. *Make sure that you branch out from the `develop` branch!* |
| 38 | +3. Make sure `Checkout locally` is selected |
| 39 | +4. Click the create branch button |
| 40 | + |
| 41 | + |
| 42 | + |
| 43 | +Now a branch has been created for you, copy the commands needed for you to use it: |
| 44 | + |
| 45 | + |
| 46 | + |
| 47 | +In you cloned repository open a terminal and paste the copied commands. Now you should be on your newly created branch and you can start working. To make sure you are on that branch run: |
| 48 | + |
| 49 | +```bash |
| 50 | +$ git branch |
| 51 | +* 16-task-number-do-something-with-something |
| 52 | +... |
| 53 | +``` |
| 54 | + |
| 55 | +The branch on which you currently reside will be marked with a `*`. |
| 56 | +Next simply keep working on your branch, push commits, and when you think you are ready create a Pull Request, make sure that you mark your PR as a draft if its not ready for review otherwise it looks like noise. |
| 57 | + |
| 58 | +## Creating a Pull Request (PR) |
| 59 | + |
| 60 | +After you create changes on your branch create a Pull Request and mark it as a `Draft` as that it can be seen that you are working on a given issue. Similarly to creating an issue ensure that: |
| 61 | + |
| 62 | +* Summary of changes in the body of the pull |
| 63 | +* Labels |
| 64 | +* Milestone |
| 65 | +* Link related issues |
| 66 | +* Assign the project `rust-pip` |
| 67 | +* etc. |
0 commit comments