triz-docs/docs/workflow/task-workflow.md

sidebar_position	title	description
1	Developer Task Workflow	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.

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.

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:

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:

git checkout -b feature/<task_number>

For example, for task #42:

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:

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

For example:

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:

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

git checkout feature/<task_number>

Step 8 — Rebase the Feature Branch onto dev

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:

git add <file>

4. Continue the rebase:

git rebase --continue

5. Repeat until the rebase completes.

If you need to abort and start over:

git rebase --abort

Step 9 — Switch to dev to Merge

git checkout dev

Step 10 — Merge the Feature Branch into dev

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:

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.

Quick Reference

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

# 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.

Branch Naming Reference

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

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