# Pull Requests
Please find here a quick guide how to create a new pull request and following "Git Flow".
We're working with Click Up (opens new window) project management system. First source of trough should be task from it then. Check if the task exists in the CU, if not create one before you start. While you have your task, either it's new, or you know one follow the steps.
Create a new branch with pattern
feature/CU-xyz123-your-task
wherexyz123
is the Click Up related task andyour-task
is a short description of it. It's really important and helpful if you add this short label, on top of that it will be easier to identify the task by other developers, even by the management stuff.Commits also must contain Click Up related task ID.
We use prefixed branches: hotfix/feature/release/bugfix
If the task is containing subtasks push the branch to the repo, even if it's empty, to collaborate with your team on it.
Branch prefixed with
release
is a candidate to deploy. It is deployed at stage env.Hotfix is always created from
master
branch.Remember to merge hotfix branch to
master
and alsodevelop
.Hotfix should fix the issue on the production. We don't look at the code if it's pretty. We will refactor it at develop branch. It must stop production issue escalation as fast as possible.
Each merge to
master
must create version tag - annotated tag (opens new window)Version codes: X.Y.Z, X - constant, changes each calendar year, Y - each merge to develop, Z - each hotfix
We don't use git rebase. We use merges with no fast forward (git merge --no-ff BRANCH).
We don't push directly to
develop
,release
or speciallymaster
branch. We always use merge requests.MR requires at least 1 approve. Even, if there is more than 1 reviewer, an approver must always check if all the issues in the comments are solved.