This page is for anyone that is getting up to speed with the dense thicket of jargon that is used by everyday practitioners who need to discuss topics related to developer workflows. If you don't want to read it entry-by-entry, here's an index:
When a programmer has accumulated enough work that they can summarize it in a message, they are able trigger a "commit" action in git, which saves their work-to-date. That means that their source code, which would have shown as "changed" by git and their IDE, will no longer show as changed, because the work is now "committed," aka "confirmed" as the programmer's official set of changes to implement whatever goal they describe in the commit message.
This refers to the number of Commits that a developer has made within a given period of time. While Commit Count is one of the most trivial metrics to "game," it is nevertheless the most reliable, widely available indicator for getting a relative sense for how much work is happening in a project. Some stats on Commit Count.
This is the term that GitClear uses to refer to an Issue Tracker Ticket of sufficient importance that a team decided to make a product release on behalf of fixing the defect. Teams often consider an issue "urgent" enough to issue a hotfix when they can measure that the presence of the bug will noticeably impact business KPIs. Other times, a defect is registered because a threshold of disgruntled customers has contacted the team. "Prevalence" and "time to resolve" for a Critical Defect are featured among the four classic DORA stats.
Another word for a "Release"
GitClear's proprietary metric that has been proven to correlate with "developer effort" better than other traditional metrics like "Commit Count" and "Lines of Code Changed." Here is a guide dedicated soley to explaining idioms and terminology within Diff Delta, with ample links to related topics.
gitThe preferred technology in the 2020s for allowing teams to modify source code in parallel as a team. On Wikipedia and Google's #1 result.
Usually, Jira. Sometimes: GitHub Issues, Linear, Trello, or Amplenote. The "Issue Tracker" is the system that a team has designated to keep track of the various projects that they are considering tackling soon.
Within an Issue Tracker, there are individual Issue Tracker Tickets. If the Issue Tracker Project is named "GitClear" and has a key of "GC", then the individual Issue Tracker Tickets will be identified as GS-1, GS-23, GS-1862, etc.
Teams that strive to operate efficiently will often estimate the amount of time/effort an Issue Tracker Ticket represents, and they will save their estimate to a column in the Issue Tracker Ticket called "Story Points." GitClear has a great deal of functionality built around exploiting the often-high correlation between "Story Points" and "Diff Delta."
An Issue Tracker groups Issue Tracker Tickets into Issue Tracker Projects. Often, an Issue Tracker Project corresponds to a particular team within a company, but individual projects can also correspond with repos, or conceptual areas of development.
When programmers are assigned a task, they need to pick out which files need to be changed in order to implement the requested change. Any line in a file that the developer modifies is a "changed line of code," but in the context of developer analytics, changed lines of code are often referred to as simply "lines of code."
Sometimes, new managers think it's possible to use "Lines of Code" as a metric, since it corresponds to the volume of change a developer is making. Unfortunately, only about 4-5% of changed lines represent meaningful work, so managers that use this as a metric are in a bad way.
In the course of implementing an issue tracker ticket, a developer often ends up changing 10s of files across 3+ commits. The "pull request" is the opportunity for a developer to describe all the changes they have made, such that they will enable their teammates to review their batch of changed code efficiently.
Anywhere you look on the internet, you'll find managers and developers alike advocating/pleaing/recommending that developers post SMALL pull requests, so that reviewers aren't overwhelmed by the prospect of reviewing thousands of lines of code. Meanwhile, back in the messary real world, this advice is generally tossed aside by developers who find that it's easier to submit a large batch of work than to keep posting numerous small changesets. It is the signature of a great manager if they can consistently incentivize their developers to submit pull requests that are 500 Diff Delta or less.
After a pull request is opened, other members of the team can be invited (formally, via a "Pull request review," or informally, on Slack etc) to review the code that is eligible to merge. When we talk about "Revision phase" code, we are talking about code changes that occur between when the developer finished writing their code, and conducting their self-audit.
When more than 30% of the work in a pull request comes during the Revision Phase, it is reason to question whether the developer might be able to more thoroughly self-review their code before submitting it for review.
An action taken to transition code from being "approved for launch" to "live for customers." According to Google DORA's annual survey, the highest performing teams successfully execute one or more Releases per day, while low-performing teams often need a month or more to finish a Release. One common factor that reduces the number of Releases is a "slow build process." Usually, executing a deploy involves building certain assets so they will arrive in a customer's browser pre-compiled, to optimize size and performance. For a new/young git repo, the steps to constitute a release might only take one minute to finish. For older, legacy projects (especially native projects, or projects that build in large libraries) the process is measured in hours. If developers need to make a change while the build is underway, that means starting over, in a process that often occurs repeatedly during times of high pressure.
A set of files that programmers change that are tracked over time. "Repo" is short for "repository," and here are "Git Repositories," as explained by GitHub. Or watch a short video on the topic.