228 lines
7.1 KiB
Markdown
228 lines
7.1 KiB
Markdown
---
|
|
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 |
|