Git Usage Standard

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?

  When working with a team on a Git-managed project, it’s important to make sure the team is aware of how the flow of changes will be applied, so that the team can accomplish work in a consistent and productive manner.

• 🎯 The goal of this article

  This article will provide the standard way of using Git in Agate

• 🤷🏻 If I have further question about this article, who can I reach out to?

  Please contact: Fachri Akbar (fachri@agate.id)

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

1. 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
2. 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	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:

1. Code contains no compile time error (compile-able)
2. 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:

1. A feature is completed
2. 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
  • else, do a body message

Merging

---

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

1. Make sure all pipeline jobs are successful

2. If there is any code conflict in the merge request, please solve it before proceeding any further

3. Mention Lead Programmer to review the merge request

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

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

6. The merge request should only be merged if:

   (1) it is not a WIP,

   (2) has been approved by the other two team members (Lead Programmer and Peer Programmer), and

   (3) all related discussions are resolved (if any)