google/eng-practicesPublicArchived

Google's Engineering Practices documentation

AI summary: A comprehensive public repository of Google's internal engineering practices and code review guidelines.

Stars
23.3K
+-2 today
Forks
2.3K
Watchers
4
Open issues
8
Open PRs
12
Contributors
~15
Commits
95
Branches
2

OtherCreated Sep 4, 2019Last push 1y ago+-7 stars this week+-8 this month

Star history

since Sep 1, 2019
010K20KSep 2019Dec 2021Mar 2024Aug 2026
23.3K stars as of Aug 7, 2026, tracked back to Sep 1, 2019. Historical curve reconstructed from public GitHub event archives, calibrated to the current total.

Contribution activity

commits per day, last 52 weeks

Signals and awards

derived from tracked data
  • Widely adopted

    23,314 stars

  • Battle-tested

    6 years of history

What eng-practices does

This repository serves as the definitive public source for Google's generalized engineering practices, distilled from decades of managing massive-scale software projects. It primarily focuses on the human processes of software engineering, notably providing extensive, detailed guidelines on how to conduct effective code reviews. The documentation covers both the responsibilities of the reviewer and the author, aiming to standardize expectations and improve code velocity without sacrificing quality. The practices presented are language-agnostic and emphasize clarity, maintainability, and psychological safety in technical environments. It acts as a foundational text for organizations looking to mature their engineering culture.

Software engineers, tech leads, and engineering managers seeking to establish or improve code review processes and overall engineering culture. Applicable to developers at all experience levels.

  • Code Review Standards: Defines explicit criteria for what reviewers should look for, balancing perfection with continuous progress.
  • Author Guidelines: Provides strategies for authors to structure CLs (Changelists) to ensure swift and painless reviews.
  • Language-Agnostic Principles: Focuses on architectural and cultural principles that apply regardless of the specific technology stack.
  • Conflict Resolution: Offers practical advice for resolving technical disagreements professionally during the review process.
  • Historical Context: Represents the collective experience and evolving standards of one of the world's largest engineering organizations.

Where teams use it

Engineering Onboarding

Engineering managers incorporate these documents into onboarding processes to align new hires with team quality expectations.

Process Standardization

Startups adopting formal code review processes use these guidelines as a foundational template to avoid common pitfalls.

Culture Improvement

Tech leads reference the conflict resolution sections to mediate disputes and foster a more collaborative review environment.

Quality Assurance

Individual developers review the guidelines to self-correct their pull requests before submitting them to peers.

Getting started: Start by reading the 'Google's Code Review Guidelines' document located in the repository root.

README

master branch

Google Engineering Practices Documentation

Google has many generalized engineering practices that cover all languages and all projects. These documents represent our collective experience of various best practices that we have developed over time. It is possible that open source projects or other organizations would benefit from this knowledge, so we work to make it available publicly when possible.

Currently this contains the following documents:

Terminology

There is some Google-internal terminology used in some of these documents, which we clarify here for external readers:

  • CL: Stands for "changelist", which means one self-contained change that has been submitted to version control or which is undergoing code review. Other organizations often call this a "change", "patch", or "pull-request".
  • LGTM: Means "Looks Good to Me". It is what a code reviewer says when approving a CL.

License

The documents in this project are licensed under the CC-By 3.0 License, which encourages you to share these documents. See https://creativecommons.org/licenses/by/3.0/ for more details.

Creative Commons License

View on GitHub

Recent activity

commits and pull requests

Recent open issues

view all

Commits per week

last 52 weeks

When work happens

weekday and hour
SunMonTueWedThuFriSat036912151821Sun 0:00 — 0 commitsSun 1:00 — 0 commitsSun 2:00 — 0 commitsSun 3:00 — 0 commitsSun 4:00 — 0 commitsSun 5:00 — 0 commitsSun 6:00 — 0 commitsSun 7:00 — 0 commitsSun 8:00 — 0 commitsSun 9:00 — 0 commitsSun 10:00 — 0 commitsSun 11:00 — 0 commitsSun 12:00 — 1 commitsSun 13:00 — 0 commitsSun 14:00 — 0 commitsSun 15:00 — 0 commitsSun 16:00 — 0 commitsSun 17:00 — 0 commitsSun 18:00 — 0 commitsSun 19:00 — 0 commitsSun 20:00 — 0 commitsSun 21:00 — 0 commitsSun 22:00 — 0 commitsSun 23:00 — 0 commitsMon 0:00 — 0 commitsMon 1:00 — 0 commitsMon 2:00 — 0 commitsMon 3:00 — 0 commitsMon 4:00 — 0 commitsMon 5:00 — 0 commitsMon 6:00 — 0 commitsMon 7:00 — 2 commitsMon 8:00 — 0 commitsMon 9:00 — 0 commitsMon 10:00 — 3 commitsMon 11:00 — 2 commitsMon 12:00 — 2 commitsMon 13:00 — 1 commitsMon 14:00 — 0 commitsMon 15:00 — 2 commitsMon 16:00 — 0 commitsMon 17:00 — 1 commitsMon 18:00 — 0 commitsMon 19:00 — 0 commitsMon 20:00 — 0 commitsMon 21:00 — 1 commitsMon 22:00 — 0 commitsMon 23:00 — 0 commitsTue 0:00 — 0 commitsTue 1:00 — 0 commitsTue 2:00 — 0 commitsTue 3:00 — 0 commitsTue 4:00 — 0 commitsTue 5:00 — 0 commitsTue 6:00 — 0 commitsTue 7:00 — 1 commitsTue 8:00 — 0 commitsTue 9:00 — 0 commitsTue 10:00 — 0 commitsTue 11:00 — 2 commitsTue 12:00 — 0 commitsTue 13:00 — 2 commitsTue 14:00 — 2 commitsTue 15:00 — 1 commitsTue 16:00 — 2 commitsTue 17:00 — 0 commitsTue 18:00 — 0 commitsTue 19:00 — 0 commitsTue 20:00 — 0 commitsTue 21:00 — 0 commitsTue 22:00 — 0 commitsTue 23:00 — 0 commitsWed 0:00 — 1 commitsWed 1:00 — 0 commitsWed 2:00 — 0 commitsWed 3:00 — 0 commitsWed 4:00 — 0 commitsWed 5:00 — 0 commitsWed 6:00 — 0 commitsWed 7:00 — 0 commitsWed 8:00 — 0 commitsWed 9:00 — 2 commitsWed 10:00 — 2 commitsWed 11:00 — 1 commitsWed 12:00 — 1 commitsWed 13:00 — 1 commitsWed 14:00 — 3 commitsWed 15:00 — 1 commitsWed 16:00 — 2 commitsWed 17:00 — 1 commitsWed 18:00 — 1 commitsWed 19:00 — 1 commitsWed 20:00 — 0 commitsWed 21:00 — 0 commitsWed 22:00 — 8 commitsWed 23:00 — 1 commitsThu 0:00 — 0 commitsThu 1:00 — 0 commitsThu 2:00 — 0 commitsThu 3:00 — 1 commitsThu 4:00 — 0 commitsThu 5:00 — 1 commitsThu 6:00 — 0 commitsThu 7:00 — 0 commitsThu 8:00 — 1 commitsThu 9:00 — 2 commitsThu 10:00 — 1 commitsThu 11:00 — 4 commitsThu 12:00 — 2 commitsThu 13:00 — 1 commitsThu 14:00 — 1 commitsThu 15:00 — 3 commitsThu 16:00 — 3 commitsThu 17:00 — 1 commitsThu 18:00 — 1 commitsThu 19:00 — 0 commitsThu 20:00 — 0 commitsThu 21:00 — 0 commitsThu 22:00 — 0 commitsThu 23:00 — 0 commitsFri 0:00 — 0 commitsFri 1:00 — 0 commitsFri 2:00 — 1 commitsFri 3:00 — 0 commitsFri 4:00 — 0 commitsFri 5:00 — 0 commitsFri 6:00 — 0 commitsFri 7:00 — 0 commitsFri 8:00 — 1 commitsFri 9:00 — 0 commitsFri 10:00 — 1 commitsFri 11:00 — 1 commitsFri 12:00 — 0 commitsFri 13:00 — 1 commitsFri 14:00 — 2 commitsFri 15:00 — 2 commitsFri 16:00 — 2 commitsFri 17:00 — 0 commitsFri 18:00 — 1 commitsFri 19:00 — 0 commitsFri 20:00 — 0 commitsFri 21:00 — 0 commitsFri 22:00 — 0 commitsFri 23:00 — 0 commitsSat 0:00 — 0 commitsSat 1:00 — 0 commitsSat 2:00 — 0 commitsSat 3:00 — 0 commitsSat 4:00 — 0 commitsSat 5:00 — 0 commitsSat 6:00 — 0 commitsSat 7:00 — 0 commitsSat 8:00 — 0 commitsSat 9:00 — 0 commitsSat 10:00 — 0 commitsSat 11:00 — 0 commitsSat 12:00 — 0 commitsSat 13:00 — 0 commitsSat 14:00 — 0 commitsSat 15:00 — 0 commitsSat 16:00 — 0 commitsSat 17:00 — 0 commitsSat 18:00 — 0 commitsSat 19:00 — 0 commitsSat 20:00 — 0 commitsSat 21:00 — 0 commitsSat 22:00 — 0 commitsSat 23:00 — 0 commits
Commit volume by weekday and hour (UTC). Larger dots mean more commits.
DateListRankStars gained
May 25, 2026daily#14+58
May 24, 2026daily#19+108