Rolling Shrine
  • Welcome to Rolling Shrine
  • RGB Principles
    • Glory Principles
    • Mission & Vision
    • Values
    • Forte
    • Spirit
    • Coaster Traits
    • Glory Principles in Daily Practices
  • RGB Branding Book
    • Brand Guideline
    • Visual Implementation
    • Brand Story
    • Brand Personality
  • Organization
    • Organization Structure
    • Accountabilities & Responsibilities
      • All Roles
      • Department & Team Leadership
        • Department Head
        • Team Lead
        • Tribe Lead
      • Manager & Project Leadership
        • Program Manager (PgM)
        • Project Manager (PM)
        • Project Leadership
          • Tech Lead
          • Design Lead
      • Project Team
        • Designer
        • Engineer
        • Quality Assurance
        • Web Administrator
      • Traffic Management
      • Archives
        • Project Manager Lead
        • Team Leader
    • Career Grade & Performance Management
    • Competencies Dictionary
  • Onboarding
    • New Coaster Onboarding
    • Project Manager Onboarding
    • Designer Onboarding
    • Engineer Onboarding
    • QA Onboarding
    • Web Administrator Onboarding
  • Production & Project Management
    • Production Pipeline
    • Solution Pipeline & Guideline
  • Design Team
    • Design Team Roles & Responsibilities
    • Information Architecture
    • Web Design System
      • Desktop View Guideline
      • Responsive View Guideline
      • Principle - Typography
      • Sticker Sheets
        • Desktop View Home Page
        • Desktop View All Pages
        • Responsive View Home Page
        • Responsive View All Pages
    • UX Writing
    • Design Audit
    • Mobile UI Technical Guideline
      • Intro: Canvas
      • Foundation
        • Typography
        • Spacing
        • Color
        • Grid & Column
      • Core Components
        • Bottom Navigation Bar
        • Button
        • Grid
        • Header
        • Selection
        • Slider
        • Status Bar
        • Text Input
        • Vertical List
      • Complex Components
      • Layout
      • Design System
      • Design System Checklist
    • Web UI Technical Guideline
      • Design System
      • Design System Checklist
  • Engineering Team
    • Software Testing
    • Git Best Practice
      • Git Commit Best Practice
    • Coding Convention
      • PHP Coding Convention
      • JavaScript Coding Convention
      • Android Coding Convention
    • JSON API Specification
    • GlorySDK for Android
    • GloryKit for iOS
    • QA Team Guideline
    • Engineering Stuff Documents
  • Work From Home
    • Best Practice
  • Documents
  • Coaster Rewards & Appreciation
    • House Party Program
    • Quarterly Award
    • Coaster Loyalty Reward
    • Overtime Appreciation
  • HR
    • Work Hour & Leave Policy
    • HRIS Talenta Onboard
    • Rolling Soft Loan
    • Review Guideline
  • Rolling Daily Log
  • Tribe Leader Guideline
  • Rolling Ekstra Kurikuler
  • COVID-19 Prevention - Studio Protocol
Powered by GitBook
On this page
  • Table of Contents
  • Writing Good Commit Messages
  • 1. Imperative Subject
  • 2. Limit Subject chars to 72
  • 3. Separate subject and body with exactly 1 line
  • 4. Use body message to explain "what" or "why" instead of "how"
  • 5. Capitalize the first char in subject
  • 6. Don't use a period (.) at the end of the subject
  • 7. Don't use emoji in your commit message
  • When to Commit
  • 1. Commit often for every task
  • 2. Don't commit half-done work
  • 3. Separate commit of bug fixes and feature addition or updates
  • 4. Test before you commit

Was this helpful?

  1. Engineering Team
  2. Git Best Practice

Git Commit Best Practice

Table of Contents

  1. Writing Good Commit Messages

  2. When To Commit

Writing Good Commit Messages

Commit message contains

subject line: tell briefly what changes have been done

body message: optional part to give more explanation about the commit

1. Imperative Subject

Write a subject line in an imperative form (bentuk aktif dalam bahasa Indonesia)

Commit messages have to complete this sentence:

"If applied, this commit will _"

or

"Jika ditambahkan, commit ini akan _"

Examples

  • If applied, this commit will Add login page layout

  • If applied, this commit will Remove deprecated methods

  • If applied, this commit will Fix a bug where app will crash when user login for the second time

  • If applied, this commit will Fix a bug on the login page

  • If applied, this commit will Release version 1.0.0

  • Jika ditambahkan, commit ini akan Memperbaiki bug pada halaman dashboard

  • Jika ditambahkan, commit ini akan Menambahkan grafik pada halaman dashboard

2. Limit Subject chars to 72

3. Separate subject and body with exactly 1 line

Update chat mechanism

- resend pending image
- add upload progress percentage
- cache 24 hours of data
Fix bug out of memory pada logger

Pada versi sebelumnya log dibuat dengan meng-append ke dalam object String. 
Hal tersebut bisa mengakibatkan OOM karena melebihi kapasitas penyimpanan String. 
Untuk menghindari hal tersebut, setiap log disimpan secara terpisah ke dalam database 
lalu akan digabungkan di dalam satu file di akhir proses.

4. Use body message to explain "what" or "why" instead of "how"

Your code should tell the story better

Do

Pada versi sebelumnya log dibuat dengan meng-append ke dalam object String. 
Hal tersebut bisa mengakibatkan OOM karena melebihi kapasitas penyimpanan String. 
Untuk menghindari hal tersebut, setiap log disimpan secara terpisah ke dalam database 
lalu akan digabungkan di dalam satu file di akhir proses.

Don't

Penulisan log dilakukan dengan mengiterasi setiap item di dalam database. 
Setiap item akan ditulis ke dalam file di dalam folder temporary. 
Jika sebelumnya sudah ada file dengan nama yang sama, tulis ulang file tersebut. 
Setelah semua proses sudah beres, semua item dihapus dari database.

5. Capitalize the first char in subject

6. Don't use a period (.) at the end of the subject

7. Don't use emoji in your commit message

git gak dipake buat chattingan mas parkun ~ some dev ops engineer to some front end developer, circa 2019

When to Commit

Atomic and granular commits make it easier for developers to understand the changes and roll them back if something went wrong. With tools like the staging area and the ability to stage only parts of a file, Git makes it easy to create very granular commits.

1. Commit often for every task

The task is a part of a feature which is standalone and can be tested

Task fitur login

layout code
validasi input
handle API

2. Don't commit half-done work

3. Separate commit of bug fixes and feature addition or updates

4. Test before you commit

PreviousGit Best PracticeNextCoding Convention

Last updated 5 years ago

Was this helpful?

Partially refers to

this link