In This Article:

🤔 Notice something is missing or not working? → Please contact Zoel (zoelbastianbach@agate.id) on Ms. Teams!

Overview

Git allows us to easily synchronize changes with other users and machines, which lets you and your teammates work on the same codebase.

❓ Why should I care about this article?
🎯 The goal of this article
🤷🏻 If I have further question about this article, who can I reach out to?

Repository Request

Every quest will need to have its own repository. When the quest is started, lead programmer has to ask to create repository for maintaining source code or other sensitive things. Here's the step for requesting versioning repository

Lead programmer send quest information to technical director or IT support that contain:
1. Quest name
2. Target platform
3. Quest start date (kickoff)
4. Active team member
5. Send info to technical director to be processed
6. Need a private repository or not
Repository URL will be sent back to you

Branching

Branching is creating a clone of project source code repository, separating code revision from the main branch (trunk).

Branch Name	Usage
master	Base for latest release version. Note that this branch is owned by Lead
develop	Base for ongoing development version. Note that this branch is owned by Lead
feature/[issue_name]	Implement feature of [issue_name]. Can only be created from develop branch
bugfix/[issue_name]	Fix bug of [issue_name]. Can only be created from develop or release branch
stable/[version_number]	Stable version, example: stable/0.5.0
hotfix/[version_number]	Hotfix for stable version of [version_number]. Example: hotfix/0.5.1. Can only be created from master
release/[version_number]	Preparation for release of [version_number]. Example: release/1.0.0. Note that this branch is owned by Lead
assets/[issue_name]	Git branch for storing your images in the repo
vfx	Git branch for the visual effects
gamedesign	Git branch for storing gamedesign

All changes and commits to the develop, release, and master branch must be in the form of a merge request, DO NOT directly commit to these branches

<aside> 💡 Initial project setup is still fine to commit to these directly

</aside>
Most feature, bugfix, or hotfix branches and merge requests will derive from an Issue opened on gitlab
Release branches can only contain bug fixes, no new features can be added
Bugfix branches will most likely come from a Bug Issue issued by a QA or external team
Feature branches will most likely come from a Feature Request Issue Issued by developers (maintainer or lead), QA, or external team

Branching Model

<aside> ℹ️ The graph below is taken from a successful git branching model article http://nvie.com/posts/a-successful-git-branching-model/

</aside>

Code Commit

Programmers only may commit code when:

Code contains no compile time error (compile-able)
Code can cause other module to fail (code not stable)

If programmer accidentally commit when above prerequisite unfulfilled, the programmer should fix or patch it immediately and commit the code again with proper comment (see Commit Guideline →)

Programmer should commit the code to the repository when:

A feature is completed
There’s some bug fix

Commit Message Guideline

A typical git commit comment should look like this one:

<type>(<optional scope>): <subject>

Example:

fix(core): game load error

Types

Type should only compromises one of this:

build: Build related changes (eg: npm related/ adding external dependencies)
chore: A code change that external user won't see (eg: change to .gitignore file or .prettierrc file)
feat: A new feature
fix: A bug fix
docs: Documentation related changes
refactor: A code that neither fix bug nor adds a feature. (eg: You can use this when there is semantic changes like renaming a variable/ function name)
perf: A code that improves performance
style: A code that is related to styling
test: Adding new test or making changes to existing test

Scope

Scope is optional, must be a noun, and it represents the section of the section of the codebase

init
runner
watcher
config
web-server
proxy
etc.

Subjects

use imperative, present tense (eg: use "add" instead of "added" or "adds")
don't use dot(.) at end
don't capitalize first letter
try to keep it less than 50 characters

Merging

After branching, merging will happen. Merging is combining the revisions from the branch to the trunk. Merging step is described below:

Make sure all pipeline jobs are successful
If there is any code conflict in the merge request, please solve it before proceeding any further
Mention Lead Programmer to review the merge request
If you really need to update the version of develop environment by merging the merge request, you can directly follow up about that merge request. Thus, the Lead Programmer can look up on it immediately.
When Lead Programmer start a discussion by commenting code on merge request, the merge request will become WIP again and team members must solve it
The merge request should only be merged if: