---
sidebar_position: 1
title: "Developer Task Workflow"
description: "Standard workflow from task assignment to completion using the rebase-then-merge strategy."
---

>**Audience:** All developers on the team. This document describes the standard workflow to follow from the moment a task is assigned to the moment it is marked as complete.

<div style={{pageBreakBefore: 'always'}}></div>

# Overview

The team uses a **rebase-then-merge** workflow. Each task is developed in isolation on its own feature branch, rebased onto the latest `dev` before merging, and then both branches are pushed to remote together. This keeps the `dev` branch history clean and linear.

<div style={{pageBreakBefore: 'always'}}></div>

# Workflow

## Step 1 — Read the Task

- Open Gitea and navigate to the issue assigned to you.
- Read the task carefully, including any comments or attachments.
- Make sure you understand the requirements before starting. If anything is unclear, ask before writing any code.

## Step 2 — Start the Timer

- Start your timer as soon as you begin working on the task.
- The timer should reflect actual working time on the task, so start it now and not before you have read and understood it.

## Step 3 — Update Your Local `dev` Branch

Before creating your feature branch, make sure your local `dev` is up to date:

```Shell
git checkout dev
git pull
```

>Never branch off a stale `dev`. Always pull first to avoid basing your work on outdated code.

## Step 4 — Create the Feature Branch

Create and immediately check out a new branch from `dev`, named after the task number:

```Shell
git checkout -b feature/<task_number>
```

For example, for task #42:

```Shell
git checkout -b feature/42
```

>The branch name must follow this exact format — `feature/` followed by the task number. This links the branch clearly to the task on Gitea.

## Step 5 — Work on the Task

- Implement the changes required by the task on your feature branch.
- Commit your work as you go with clear, descriptive commit messages:

```Shell
git add .
git commit -m "#<task_number> - Short description of what was done"
```

For example:

```Shell
git commit -m "#42 - Add stock export to Excel functionality"
```

>You may have as many commits as needed on your feature branch.

## Step 6 — Update `dev` Again Before Rebasing

Before rebasing, fetch the latest changes from remote so your rebase is based on the most current state of `dev`:

```Shell
git checkout dev
git pull
```

>This step is important. If another developer pushed to `dev` while you were working, you need those changes before you rebase, otherwise you may introduce conflicts or overwrite work.

## Step 7 — Switch Back to Your Feature Branch

```Shell
git checkout feature/<task_number>
```

## Step 8 — Rebase the Feature Branch onto `dev`

```Shell
git rebase dev
```

This replays your commits on top of the latest `dev`, as if you had started your work from the current state of the branch. The result is a clean, linear history with no unnecessary merge commits from intermediate states.

>If conflicts arise during the rebase:
>1. Git will pause and show which files have conflicts.
>2. Open the conflicting files, resolve the conflicts manually.
>3. Stage the resolved files:
>```Shell
>git add <file>
>```
>4. Continue the rebase:
>```Shell
>git rebase --continue
>```
>5. Repeat until the rebase completes.
>
>If you need to abort and start over:
>```Shell
>git rebase --abort
>```

## Step 9 — Switch to `dev` to Merge

```Shell
git checkout dev
```

## Step 10 — Merge the Feature Branch into `dev`

```Shell
git merge feature/<task_number>
```

Because the feature branch was just rebased onto `dev`, this merge will be a fast-forward and will produce a clean merge commit on top of `dev`.

## Step 11 — Push Both Branches to Remote

Push both the `dev` branch and the feature branch to remote in one operation from NetBeans, or via the terminal:

```Shell
git push origin dev
git push origin feature/<task_number>
```

>Both branches must be pushed. Pushing `dev` makes your work available to the rest of the team. Pushing the feature branch keeps the remote in sync and preserves the full history of the task for reference.

## Step 12 — Copy the Merge Commit Hash from Gitea

1. Open Gitea and navigate to the **`dev` branch** of the Stock repository.
2. The most recent commit at the top of the branch is the merge commit produced in Step 10.
3. Copy the commit hash shown next to it.

>This is the hash that identifies exactly what was merged and when. It is the definitive reference for the work done in this task.

## Step 13 — Update the Task on Gitea

Go back to the issue assigned to you and post a comment containing:
- The **merge commit hash** copied in Step 12
- A **description of what was done** — what was implemented, any decisions made, anything relevant for the reviewer or for future reference

Example comment:

```
Commit: a3f1c7d

Implemented the Excel export feature for the stock listing page.
Added a new ExportService class, hooked it into the existing StockController,
and used the aspose-cells library for the file generation.
Tested with datasets of up to 10,000 rows.
```

## Step 14 — Stop the Timer

Stop your timer. The task is complete.

<div style={{pageBreakBefore: 'always'}}></div>

# Quick Reference

For experienced developers, here is the full sequence of commands in order:

```Shell
# Get latest dev
git checkout dev
git pull

# Create and switch to feature branch
git checkout -b feature/<task_number>

# ... do your work, commit as you go ...

# Get latest dev again before rebasing
git checkout dev
git pull

# Switch back to feature branch and rebase
git checkout feature/<task_number>
git rebase dev

# Merge into dev
git checkout dev
git merge feature/<task_number>

# Push both branches
git push origin dev
git push origin feature/<task_number>
```

Then go to Gitea: copy the merge commit hash from the top of `dev`, post it on the task with a description, and stop the timer.

<div style={{pageBreakBefore: 'always'}}></div>

# Branch Naming Reference

| Type | Format | Example |
|---|---|---|
| Development branch | `dev` | `dev` |
| Feature branch | `feature/<task_number>` | `feature/42` |

<div style={{pageBreakBefore: 'always'}}></div>

# Common Mistakes to Avoid

| Mistake                                        | Why it is a problem                                                  |
| ---------------------------------------------- | -------------------------------------------------------------------- |
| Branching off `dev` without pulling first      | Your feature branch starts from stale code, causing conflicts later  |
| Skipping the second `git pull` before rebasing | You rebase on an outdated `dev` and miss changes from teammates      |
| Forgetting to rebase before merging            | Produces a messy history with unnecessary intermediate merge commits |
| Pushing only `dev` and not the feature branch  | The feature branch on remote becomes out of sync                     |
| Pushing only the feature branch and not `dev`  | Your work never reaches the team                                     |
| Not posting the commit hash on the task        | The task has no traceable link to the code that implements it        |