Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

TL;DR: many edX tools and scripts depend upon Git commit messages so it is important that we are consistent in our usage.

Table of Contents

Configuration

It is recommended that all developers run the following Git configuration commands:

git config --global --add branch.autosetupmerge true
git config --global --add branch.autosetuprebase always
git config --global --add push.default simple

Git has an issue with files containing unicode characters in their file name on any system using HFS+ filesystem. If you use a Mac and experience an untracked file immediately upon cloning the edx-platform repo, try running the following configuration command:

git config --global core.precomposeunicode false


Commit Messages

  • Many edX tools and scripts depend upon consistency in Git commit messages
    • Many tools including GitHub assume the presence of a short title
    • Release scripts and others can extract the ticket numbers to include in a list of commits
    • JIRA links tickets to any commits that include that ticket's number
  • We follow the 50/72 rule for writing commit messages
    • The first line of a commit message should be a title in 50 characters or less.
    • Further comments should be paragraphs wrapped to 72 characters
    • Include the JIRA ticket number on its own line to be picked up by scripts
  • Example commit message:

    • https://github.com/edx/edx-platform/commit/978e9fe656bb249237ba1ceea0ebec1aa0b06fa7

      Fix inline discussions to use cached static assets

In production environments, the DiscussionXBlock was generating CSS and
JS asset URLs that pointed to the unminified versions of those bundled
assets. Due to our nginx rules, this would cause the assets to be
served without the long expiration times, forcing the user's browser to
constantly refetch these assets while browsing a course.

PERF-431
  • Here are a few blog posts that explain the rationale behind these rules:

Squashing commits

  • Squash commits (as appropriate) before requesting a review.
  • Do not squash commits once a review has started, to aid reviewers.
  • Squash commits after the review, before merging a PR.

See Also

  • No labels