-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update pull_request_template.md #1713
base: hotfix-merge-2024-09-26
Are you sure you want to change the base?
Conversation
Document workflow for hotfix branch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should discuss this at our next dev meeting. Individual hotfixes rarely involve more than a commit or two, and thus probably don't need to be squashed when merged into 'hotfix', especially because the final hotfix will be squash merged into 'master'. But maybe better to discuss as a group.
I am good with changing the language to a normal merge. I think I was confused about what we had discussed. Now that you mention it I agree that a normal merge is better as it allows for for individual commit cherry picking / rollbacks prior to merging the hotfix branch into master - when it will be squashed. |
Adjusted hotfix merge instructions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requested one logic and one typo fix.
@@ -17,8 +17,11 @@ | |||
|
|||
- [ ] It is the code author's responsibility to merge their own pull request after it has been approved | |||
- [ ] If this PR represents a merge into the `Development` branch, remember to use the **squash & merge** option | |||
- [ ] If this PR represents a merge into the `hotfix` branch, remember to use the **squash & merge** option |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just, squash here as well, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just merge into the hotfix branch, since the hotfix branch will be eventually Squash & Merged into Master. We don't need to Squash Merge twice.
- [ ] If this PR represents a hotfix into the `master` branch, a subsequent PR from `master` into `Development` should be made **merge** option (i.e., no squash). | ||
- [ ] If this PR represents a merge from the `hotfix` branch into the `master` branch use the **squash & merge** option | ||
- [ ] a subsequent PR from `master` into `Development` should be made with the **merge** option (i.e., no squash). | ||
- [ ] **Immediatly** after merging into `master` and `Development` increment the Symbiota version number in the symbase.php file and commit to the `hotfix` branch. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo with immediately here.
Description
Document workflow for hotfix branch
Pull Request Checklist:
Pre-Approval
master
branch and squash and merged into thehotfix
branch.Development
branch, NOTmaster
Post-Approval
Development
branch, remember to use the squash & merge optionDevelopment
branch into the master branch, remember to use the merge optionmaster
branch, a subsequent PR frommaster
intoDevelopment
should be made merge option (i.e., no squash).Development
branch before a tagged release (i.e., before an imminent merge into the master branch), make sure to notify the team and lock theDevelopment
branch to prevent accidental merges while QA takes place. Follow the release protocol here.Thanks for contributing and keeping it clean!