Skip to main content
Version: Sprint 4

Git Methodology

1. Introduction​

This project uses Git for version control and Gitea as the central repository hosting platform. The purpose of the version control methodology is to support collaborative development while protecting the stability of the main project codebase.

The team follows a branch-based workflow in which developers complete assigned tasks on separate branches before integrating their work into the main branch. This approach reduces the risk of unfinished or unstable code being introduced directly into the production codebase and allows multiple team members to work on different tasks simultaneously.

2. Central Repository​

The project is maintained in a shared Gitea repository, which serves as the central location for the project's source code and version history.

All team members work from the same repository and are expected to follow the agreed branching and commit methodology. The repository provides a shared history of changes, allowing the team to track the development of the project and identify which changes were made for specific tasks.

The repository uses a main branch as the primary and stable version of the project.

3. Main Branch​

The main branch represents the primary and most stable version of this project.

Team members do not use the main branch as their primary development workspace. Instead, changes are developed and tested on individual task branches before being integrated into main.

Code should only be merged into the main branch when:

  • The assigned task has been completed.
  • The developer has finished the required work.
  • No unresolved issues remain.
  • The changes have been reviewed as part of the merge process.
  • Any merge conflicts or integration issues have been resolved.

This ensures that the main branch remains stable and contains completed work rather than unfinished or experimental changes.

4. Task-Based Branching​

When a team member is assigned a task, they create a separate Git branch specifically for that task.

Each developer performs their work within their assigned branch rather than making changes directly to the main branch. This allows different team members to work independently and prevents incomplete work from affecting the central project code.

A typical branch may be created using a naming convention related to the assigned task, for example:

feature/authentication
feature/tape-animation
feature/user-interface
fix/login-error

The use of task-specific branches provides several advantages:

  • Multiple tasks can be developed simultaneously.
  • Incomplete work remains isolated from the stable main branch.
  • Changes can be reviewed before integration.
  • Problems can be identified without affecting other completed features.
  • The history of work performed for a specific task remains easier to track.

5. Commit Methodology​

Developers are expected to make commits while working on their assigned task branches. We use conventional commits and we optionally omit the scope. The commit messenger extension is also optionally utlized.

Commits should represent meaningful stages of development rather than waiting until the entire task is complete before committing all changes at once. Regular commits provide a clear history of how the task was developed and allow changes to be tracked and recovered if necessary.

Examples of meaningful commits include:

Implement tape cell component
Add head movement functionality
Fix execution state update
Update authentication route

Commiting regularly provides several benefits:

  • Changes are backed up to the shared repository.
  • Development progress is visible to the team.
  • Earlier versions of the code can be recovered if required.
  • Problems can be traced to specific changes.
  • Merge and review processes are easier to manage.

6. Merging into the Main Branch​

Once a developer has completed their assigned task, they must ensure that the work is functioning correctly and that no known issues remain before requesting a merge into the main branch.

The merge process is conducted with the Scrum Master present. This provides an additional level of oversight during integration and ensures that any problems encountered during the merge can be discussed and resolved collaboratively.

During the merge process, the team may need to address:

  • Merge conflicts.
  • Conflicting changes made by different developers.
  • Integration problems between features.
  • Issues discovered when combining the task branch with the latest version of main.

If issues are identified, they should be resolved before the merge is considered complete. The objective is to ensure that the resulting main branch remains functional and stable.

7. Branch Deletion​

A task branch may only be deleted once the team member has confirmed that the assigned task is complete and that the work has been successfully integrated into the project.

Before deleting a branch, the following should be confirmed:

  1. The assigned task has been completed.
  2. The required changes have been committed.
  3. The work has been successfully merged into the main branch.
  4. No additional work is required on that branch.
  5. Any issues identified during the merge process have been resolved.

Deleting completed branches helps maintain a clean and organised repository by removing branches that are no longer required.

Branches containing unfinished work should not be deleted.

8. Standard Development Workflow​

The standard Git workflow for this project can be summarised as follows:

Step 1: Receive an Assigned Task​

A developer is assigned a specific task or feature to implement.

Step 2: Create a Task Branch​

The developer creates a separate branch from the current project codebase.

main
  └── feature/task-name

Step 3: Develop on the Task Branch​

All work related to the assigned task is performed on the task branch.

The developer does not directly develop on the main branch.

Step 4: Commit Changes Regularly​

The developer creates regular commits as meaningful stages of the task are completed.

Task Branch
   ├── Commit: Initial implementation
   ├── Commit: Add functionality
   ├── Commit: Fix issues
   └── Commit: Final changes

Step 5: Complete and Verify the Task​

Once the task is complete, the developer verifies that the implementation is functioning correctly and that there are no known issues.

Step 6: Merge with Scrum Master Present​

The task branch is merged into the main branch with the Scrum Master present.

Any merge conflicts or integration issues are resolved during this process.

Step 7: Delete the Completed Branch​

Once the merge has been completed successfully and no further work is required, the task branch may be deleted.

The workflow can therefore be represented as:

        main
          │
          ├───────────┐
          │           │
          ▼           │
   Create Task Branch │
          │           │
          ▼           │
      Development     │
          │           │
          ▼           │
   Regular Commits    │
          │           │
          ▼           │
    Task Complete     │
          │           │
          ▼           │
   Merge with Scrum   │
   Master Present     │
          │           │
          ▼           │
    Resolve Issues    │
          │           │
          ▼           │
      Update main ────┘
          │
          ▼
    Delete Branch

9. Conclusion​

This project's Git methodology is based on a task-based branching strategy designed to maintain code stability and support collaborative development.

The main branch represents the stable version of the project, while individual developers work on separate branches for their assigned tasks. Developers make regular commits throughout development, providing a clear and recoverable history of their work.

Once a task has been completed and verified, the branch is merged into main with the Scrum Master present. Any merge conflicts or integration issues are resolved before the process is completed. Branches are only deleted once their associated tasks have been completed and their changes have been successfully integrated.

Methodology Summary​

Assign Task → Create Task Branch → Develop → Commit Regularly → Verify Completion → Merge with Scrum Master → Resolve Issues → Update Main → Delete Completed Branch

This methodology provides this project with a structured, collaborative, and controlled approach to version management while ensuring that the main branch remains stable and that completed work is integrated carefully.

Diagrams and format compiled by Claude Sonnet 5.