ClickUp Bitbucket Laravel Forge

Enterprise delivery workflow

Git Branching, Task Workflow, and Deployment Process

One operating model from task assignment to production release across Local, DEV, and PROD.

Standard handoffs

What the system controls

  • Task status moves in ClickUp as the work changes hands.
  • Branches and pull requests flow through Bitbucket in a predictable order.
  • DEV and PROD deployments happen from fixed branches through Laravel Forge.

Core path

Local -> DEV -> PROD, with review gates before each environment jump and explicit return paths back to OPEN when feedback appears.

What this deck standardizes

Each stage has a branch, a status, an owner, and a deployment target.

01

Branching strategy

Permanent branches stay stable; feature branches map to ClickUp work.

02

Task statuses

OPEN through CLOSED defines where the task is and who owns it.

03

Review gates

Peer review protects dev, then PM and client review protect production.

04

Deployment flow

DEV deploys after peer-review merge; PROD deploys only after approval.

05

Responsibilities

Developer, reviewer, PM, and deployment owner each have a clean boundary.

06

Rules and happy path

The workflow stays safe because direct pushes and approval bypasses are off-limits.

Permanent branches

`main` and `dev` are environment branches

main

Production branch for PROD. It must stay stable and is deployed to production through Forge.

dev

Development and staging branch for DEV. It is the client review surface before anything reaches production.

Environment map

Local uses the feature branch, DEV tracks dev, and PROD tracks main.

Feature branches

One task, one branch

feature/<CLICKUP_TASK_ID>-short-description

Example: feature/CU-1234-add-user-export

  • Continue using the ClickUp ID in the branch name.
  • The prefix follows the tag the PM decides.
  • If the task has no tag, the developer chooses the prefix.

ClickUp workflow

Statuses tell the team exactly where the task sits

The first group tracks active engineering work. The second group tracks approval, deployment readiness, and closure.

Execution statuses

Developer and reviewer movement

OPEN - task is ready to be worked on.
IN PROGRESS - developer is actively working locally.
ON LOCAL - code is complete locally, but not yet pushed and no PR exists.
PEER REVIEW - PR to dev exists and is waiting for code review.

Approval and release statuses

PM and client movement

PM REVIEW - PR to main is awaiting project manager approval.
CLIENT REVIEW - work is on DEV and waiting for client feedback.
DEPLOY - client approved the change and it is ready for production deployment.
DONE - production deployment is complete.
CLOSED - PMs can move the task into its final closed state.

Loopback rule

Rejection during peer review, PM review, or client review sends the task back to OPEN and back to the original developer for another local cycle.
flowchart TD
    A["OPEN"] --> B["IN PROGRESS"]
    B --> C["ON LOCAL"]
    C --> D["PR: feature/* -> dev"]
    D --> E["PEER REVIEW"]
    E -->|approved| F["Merge into dev"]
    F --> G["Deploy dev to DEV"]
    G --> H["PR: dev -> main"]
    H --> I["PM REVIEW"]
    I -->|approved| J["CLIENT REVIEW"]
    J -->|approved| K["DEPLOY"]
    K --> L["Merge into main"]
    L --> M["Deploy main to PROD"]
    M --> N["DONE"]
    E -->|changes requested| A
    I -->|rejected| A
    J -->|client rejected| A

Full task lifecycle

Happy path

The order of operations is fixed

1

Start work

Move the ClickUp task to IN PROGRESS and branch from main.

2

Finish locally

Commit regularly, then move the task to ON LOCAL.

3

Peer review

Push the branch, open the PR to dev, and assign a reviewer.

4

DEV deployment

After merge, deploy dev to the DEV environment.

5

PM review

Open the PR from dev to main and hand off to the PM.

6

Client review

The PM manages review on DEV until approval.

What breaks the line

Requested changes always send the task back to OPEN so the same branch can move through the workflow again cleanly.

3.2 Development phase

Local work starts from `main`

git checkout main
git pull
git checkout -b feature/<TASK_ID>-description
  • Move the task to IN PROGRESS before coding starts.
  • Implement locally and commit regularly while the branch stays isolated.
  • When the code is complete on the machine, move the task to ON LOCAL.

3.3 PR to DEV

Peer review decides whether `dev` moves

feature/<TASK_ID> -> dev
  • Push the branch to Bitbucket and create the PR to dev.
  • Assign another developer as reviewer.
  • Update ClickUp to PEER REVIEW, reassign to the reviewer, and add the PR link.
  • If approved, the reviewer merges into dev and deploys DEV through Forge.
  • If changes are requested, the task returns to OPEN.

3.5 and 3.6

PM review and client review happen on the way to release

PM REVIEW

After the PR from dev to main is created, the PM reviews scope, context, and readiness.

CLIENT REVIEW

Approved work is reviewed on DEV. If the client rejects it, the task goes back to OPEN and the local workflow restarts.

When the client approves, the PM moves the task to DEPLOY and assigns the deployment developer.

3.7 Production deployment

Only `main` goes to PROD

dev -> main
Forge deploys main -> PROD
  • The deployment developer merges the reviewed dev PR into main.
  • Forge deploys main to production.
  • The task moves to DONE and is handed back to the PM.

Deployment summary

Each environment has one branch trigger

Local

Branch: feature/*

Trigger: developer work on the task branch.

DEV

Branch: dev

Trigger: merge after peer review.

PROD

Branch: main

Trigger: client approval and deployment merge.

Responsibility matrix

Who owns each handoff

Developer - creates the feature branch, builds locally, opens PRs, and fixes feedback.
Peer reviewer - reviews the PR to dev, approves or rejects it, and deploys DEV after merge.
Project manager - approves the PR to main, manages client review, and authorizes deployment.
Deployment developer - merges to main and deploys production.

Rules and best practices

Guardrails that keep the process healthy

  • Never commit directly to dev or main.
  • Every change must go through pull requests.
  • Always reference the ClickUp task ID in branch names and preferably in PR titles and commits.
  • Keep pull requests small, focused, and easy to review.
  • Always deploy dev after feature branches merge.
  • No production deploy happens without client approval.

Happy path timeline

The expected state changes

1

OPEN

Task is created and assigned.

2

IN PROGRESS

Developer starts local work.

3

ON LOCAL

Implementation is complete on the branch.

4

PEER REVIEW

PR to dev is open.

5

PM REVIEW

PR from dev to main is waiting on approval.

6

CLIENT REVIEW

The work is live on DEV.

7

DEPLOY

Client approved; production release is queued.

8

DONE

Merged to main and deployed to PROD.