{"id":1415,"date":"2024-06-08T00:00:00","date_gmt":"2024-06-07T22:00:00","guid":{"rendered":"https:\/\/demo.sidekick.be\/itenium\/git-pull-request-hygiene\/"},"modified":"2025-11-28T13:31:42","modified_gmt":"2025-11-28T12:31:42","slug":"git-pull-request-hygiene","status":"publish","type":"post","link":"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/","title":{"rendered":"Git Pull Request Hygiene"},"content":{"rendered":"

You basically want to avoid forcing your colleagues to review mega PRs for what could have been much smaller, right?<\/p>\n

\"Everyone<\/p>\n

These either result in your PR being open for a very long time (with all the merge conflicts that entails!) or the reviewer losing patience\/focus and just approving after the first 20 files \u2013 both are outcomes that are not ideal.<\/p>\n

PR Preparation<\/h1>\n

Step 1: Stage your changes<\/h2>\n
# Shorter\ngit add -p\n\n# Or even shorter with an alias\ngit config --global alias.adp 'add -p'\n<\/code><\/pre>\n
git add \u2013patch<\/strong>
 Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.<\/p>\n
Note that this will not add new files, you still have to add those with a git add new_file<\/code>!<\/p>\n
For each hunk you have a few options, the most common:<\/p>\n\n\n\n\n\n\n\n\n\n
Key<\/th>\nMeaning<\/th>\n<\/tr>\n<\/thead>\n
y\/n<\/td>\nAdd or don\u2019t add the hunk<\/td>\n<\/tr>\n
a\/d<\/td>\nAdd all hunks in the file or skip to the next file<\/td>\n<\/tr>\n
s<\/td>\nSplit the hunk into smaller ones<\/td>\n<\/tr>\n
e<\/td>\nDecide manually on a line-per-line basis<\/td>\n<\/tr>\n
q<\/td>\nQuit. Whenever it turns out there is still some work left!<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Step 2: Review the staging area<\/h2>\n
Before doing the actual commit, go over all staged changes: are you about to commit everything that is needed, and nothing more?<\/p>\n
git diff --staged\n\n# With an alias of course!\ngit config --global alias.dfc 'diff --staged'\n<\/code><\/pre>\n
Step 3: Commit!<\/h2>\n
\"Commit<\/p>\n
Don\u2019t write your life\u2019s story (at least not in a commit message!) but do add something meaningful, what exactly are you changing? Are you fixing a bug, improving performance, doing source-code cleanup, a refactoring or are you implementing a new feature?<\/p>\n
I always try to get the entire team onboard for starting each commit message with a ticket ID<\/strong> so that there is always a link back to your bug tracking system or Scrum board. These artifacts are typically long-lived and may contain additional information like a link to the analysis, comments from team members, file attachments etc!<\/p>\n
Step 4: Create the PR<\/h2>\n
You obviously also want to automate this! See our blog post on exotic git snippets<\/a> for a small script to create a PR like a breeze.<\/p>\n
# Creating a PR from the commandline:\npr\n<\/code><\/pre>\n
Check the \u201cFiles changed\u201d<\/h3>\n
Since a PR typically exists of multiple commits, before sending the PR to your colleague, make sure to go through all your changes one last time.<\/p>\n
Consider a PR checklist<\/h3>\n
Most systems allow you to create a file like .github\/pull_request_template.md<\/code><\/a> where you can add a checklist of things that are recurring comments from reviewer(s) that could\u2019ve been easily catched by the PR creator.<\/p>\n
Poor Hygiene Examples<\/h1>\n
Lingering debug statements<\/h2>\n
The PR still contains statements that a quick glance would\u2019ve catched:<\/p>\n
console.log('val', someValue);\ndebugger;\n\/\/ TODO: xyz\n<\/code><\/pre>\n
You made some changes to speed up your manual testing, that is OK but make sure you don\u2019t commit this!!<\/p>\n
function isLoggedIn() {\n  \/\/ return !!this.userService.token;\n  return true;\n}\n<\/code><\/pre>\n
Should never have been committed<\/h2>\n
Earlier this week I deleted an HTML file which contained local test run results.<\/p>\n
Typically everything that is generated should not be committed as it can just be re-generated on the fly!
 There are exceptions, for example a package-lock.json<\/code> is generated but is used by a CI\/CD pipeline to make sure new npm install<\/code>s the exact same thing.<\/p>\n
Deleting such files is not enough though, create a PR to add the file\/folder to your .gitignore<\/code> so that this can never happen again!<\/p>\n
When in doubt whether you should .gitignore<\/code> something, google it!<\/p>\n
Avoid Superfluous Changes<\/h2>\n
These are changes that typically happen automatically on a save and means that someone has a different linter installed, or that they are running their linter with different settings \ud83d\ude32<\/p>\n
-  constructor(private socksService: SocksService) {}\n+  constructor(private socksService: SocksService) { }\n<\/code><\/pre>\n
Another classic, with one keystroke you can add missing imports but of course your default IDE configuration is different from the style that is used in 99% of the rest of the code base.<\/p>\n
Fix your configuration or fix the styling, please!<\/p>\n
import { Review } from '.\/sock.model';\n+import {TimeAgoPipe} from '..\/time-ago.pipe';\n<\/code><\/pre>\n
It\u2019s cool to have an .editorconfig<\/code><\/a> but if not all devs have the plugin installed in their IDE, it is pretty useless:<\/p>\n
-}\n+}\n No newline at end of file\n<\/code><\/pre>\n
Same for some extra whitespace at the end of a line: <router-outlet \/><\/code> vs <router-outlet \/> <\/code>. Please don\u2019t \ud83e\udd7a<\/p>\n
Note that a git hook, for example with Husky<\/a>, can pretty much solve this in your team by automatically fixing all linting issues right before a commit.<\/p>\n
Not Needed After All<\/h2>\n
If your first hunk is this one and there are no others in the same file, I guess you moved the code to somewhere else and forgot to clean up your import statements!<\/p>\n
+import { LOCALE_ID } from '@angular\/core';\n<\/code><\/pre>\n
You added a new package but didn\u2019t end up actually using it or ended up using another one? Remove the dependency!<\/p>\n
\"dependencies\": {\n+  \"cool-package-i-did-not-use-in-the-end\": \"1.0.0\",\n+  \"@types\/cool-package-i-did-not-use-in-the-end\": \"1.0.0\",\n}\n<\/code><\/pre>\n
Also note that dev stuff should be in devDependencies<\/code>!<\/p>\n
Local Configuration<\/h2>\n
Manual or automatic changes for local dev configuration should never be checked in! That db connectionString on your local machine has no place being in the official repo. Check our blog post on Git Skip Worktree<\/a> how you can make it easier to avoid this.<\/p>\n
You are also opening up your project for a merge conflict on pretty much every PR until eternity\u2026<\/p>\n
\/\/ PR from colleague A\n\"cli\": { \"analytics\": false }\n\n\/\/ PR from colleague B\n\"cli\": { \"analytics\": \"guid\" }\n<\/code><\/pre>\n
Generated and Useless<\/h2>\n
ng generate<\/code>\u2026 So cool, so easy, and so many useless files that all get checked in.<\/p>\n
For each generated component there is a component.scss<\/code> file. And even if there is not a single styling rule added, obviously the file gets checked in.<\/p>\n
This is more an issue of \u201cwriting vs reading code\u201d. Code is written once, and then read many times over. Do you want to spend time opening empty files, just to find out it is indeed, empty? I know I don\u2019t.<\/p>\n
The other useless file is the .spec.ts<\/code>:<\/p>\n
describe('MyPipe', () => {\n  it('creates an instance', () => {\n    const pipe = new MyPipe();\n    expect(pipe).toBeTruthy();\n  });\n});\n<\/code><\/pre>\n
This test will, literally, never<\/strong> fail. The new<\/code> operator works, I guarantee it!<\/p>\n
So either delete the file, or, even better, actually write some tests for it!! Especially as is the case here, writing tests for an Angular Pipe<\/a> is very straightforward!<\/p>\n
Another thing the code generator seems to be doing from time to time, re-order statements:<\/p>\n
-  imports: [NgIf, AsyncPipe, TitleCasePipe],\n-  templateUrl: '.\/sock.component.html'\n+  templateUrl: '.\/sock.component.html',\n+  imports: [NgIf, AsyncPipe, TitleCasePipe, CurrencyPipe],\n<\/code><\/pre>\n
This makes the PR look bigger than it really is, and also harder to spot what has actually changed.<\/p>\n
Conclusion<\/h1>\n
Keep your PR short & sweet, a mere glance through all changed files will spot almost all these things.<\/p>\n
It allows you<\/strong> to fix them instead getting comments from the PR reviewer, that I would say are a bit embarrassing, especially when it happens time and time again\u2026<\/p>\n
Here\u2019s one last meme to keep the mood light:<\/p>\n
\"Yup,<\/p>\n","protected":false},"excerpt":{"rendered":"
It seems that pretty much everyone is using some sort of UI for their git interactions.<\/p>\n
Which is obviously fine, until they are about to create a commit, in which case it\u2019s using the \u201cadd all changes\u201d-button and commit.<\/p>\n
Good PR hygiene starts with keeping your commits small and focused: check your changes and exclude everything that is not part of the UserStory per se.<\/p>\n
That\u2019s why I advocate the use of git add --patch<\/code> which gives you fine-grained control of exactly what you\u2019re going to commit!<\/p>\n","protected":false},"author":1,"featured_media":1993,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[19],"tags":[26,10],"class_list":["post-1415","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-productivity","tag-git","tag-war-story"],"acf":[],"yoast_head":"\nGit Pull Request Hygiene - Itenium<\/title>\n<meta name=\"robots\" content=\"noindex, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Git Pull Request Hygiene - Itenium\" \/>\n<meta property=\"og:description\" content=\"It seems that pretty much everyone is using some sort of UI for their git interactions.Which is obviously fine, until they are about to create a commit, in which case it\u2019s using the \u201cadd all changes\u201d-button and commit.Good PR hygiene starts with keeping your commits small and focused: check your changes and exclude everything that is not part of the UserStory per se.That\u2019s why I advocate the use of git add --patch which gives you fine-grained control of exactly what you\u2019re going to commit!\" \/>\n<meta property=\"og:url\" content=\"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/\" \/>\n<meta property=\"og:site_name\" content=\"Itenium\" \/>\n<meta property=\"article:published_time\" content=\"2024-06-07T22:00:00+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-11-28T12:31:42+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/demo.sidekick.be\/itenium\/wp-content\/uploads\/2025\/11\/git-hygiene.png\" \/>\n\t<meta property=\"og:image:width\" content=\"360\" \/>\n\t<meta property=\"og:image:height\" content=\"300\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Usdevelop\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Usdevelop\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"6 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/\",\"url\":\"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/\",\"name\":\"Git Pull Request Hygiene - Itenium\",\"isPartOf\":{\"@id\":\"https:\/\/demo.sidekick.be\/itenium\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/demo.sidekick.be\/itenium\/wp-content\/uploads\/2025\/11\/git-hygiene.png\",\"datePublished\":\"2024-06-07T22:00:00+00:00\",\"dateModified\":\"2025-11-28T12:31:42+00:00\",\"author\":{\"@id\":\"https:\/\/demo.sidekick.be\/itenium\/#\/schema\/person\/6ab401ce01e858184ee4a8667fe0f022\"},\"breadcrumb\":{\"@id\":\"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/#primaryimage\",\"url\":\"https:\/\/demo.sidekick.be\/itenium\/wp-content\/uploads\/2025\/11\/git-hygiene.png\",\"contentUrl\":\"https:\/\/demo.sidekick.be\/itenium\/wp-content\/uploads\/2025\/11\/git-hygiene.png\",\"width\":360,\"height\":300,\"caption\":\"git hygiene\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/demo.sidekick.be\/itenium\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Git Pull Request Hygiene\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/demo.sidekick.be\/itenium\/#website\",\"url\":\"https:\/\/demo.sidekick.be\/itenium\/\",\"name\":\"Itenium\",\"description\":\"We build software. We build careers.\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/demo.sidekick.be\/itenium\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/demo.sidekick.be\/itenium\/#\/schema\/person\/6ab401ce01e858184ee4a8667fe0f022\",\"name\":\"Usdevelop\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/demo.sidekick.be\/itenium\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/cc8cf9b9e9d5bbe7e8d247907cc9ac8457bbfa2854b52eaddf6529adfe88ceab?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/cc8cf9b9e9d5bbe7e8d247907cc9ac8457bbfa2854b52eaddf6529adfe88ceab?s=96&d=mm&r=g\",\"caption\":\"Usdevelop\"},\"sameAs\":[\"https:\/\/demo.sidekick.be\/itenium\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Git Pull Request Hygiene - Itenium","robots":{"index":"noindex","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"og_locale":"en_US","og_type":"article","og_title":"Git Pull Request Hygiene - Itenium","og_description":"It seems that pretty much everyone is using some sort of UI for their git interactions.Which is obviously fine, until they are about to create a commit, in which case it\u2019s using the \u201cadd all changes\u201d-button and commit.Good PR hygiene starts with keeping your commits small and focused: check your changes and exclude everything that is not part of the UserStory per se.That\u2019s why I advocate the use of git add --patch which gives you fine-grained control of exactly what you\u2019re going to commit!","og_url":"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/","og_site_name":"Itenium","article_published_time":"2024-06-07T22:00:00+00:00","article_modified_time":"2025-11-28T12:31:42+00:00","og_image":[{"width":360,"height":300,"url":"https:\/\/demo.sidekick.be\/itenium\/wp-content\/uploads\/2025\/11\/git-hygiene.png","type":"image\/png"}],"author":"Usdevelop","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Usdevelop","Est. reading time":"6 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/","url":"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/","name":"Git Pull Request Hygiene - Itenium","isPartOf":{"@id":"https:\/\/demo.sidekick.be\/itenium\/#website"},"primaryImageOfPage":{"@id":"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/#primaryimage"},"image":{"@id":"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/#primaryimage"},"thumbnailUrl":"https:\/\/demo.sidekick.be\/itenium\/wp-content\/uploads\/2025\/11\/git-hygiene.png","datePublished":"2024-06-07T22:00:00+00:00","dateModified":"2025-11-28T12:31:42+00:00","author":{"@id":"https:\/\/demo.sidekick.be\/itenium\/#\/schema\/person\/6ab401ce01e858184ee4a8667fe0f022"},"breadcrumb":{"@id":"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/#primaryimage","url":"https:\/\/demo.sidekick.be\/itenium\/wp-content\/uploads\/2025\/11\/git-hygiene.png","contentUrl":"https:\/\/demo.sidekick.be\/itenium\/wp-content\/uploads\/2025\/11\/git-hygiene.png","width":360,"height":300,"caption":"git hygiene"},{"@type":"BreadcrumbList","@id":"https:\/\/demo.sidekick.be\/itenium\/blog\/productivity\/git-pull-request-hygiene\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/demo.sidekick.be\/itenium\/"},{"@type":"ListItem","position":2,"name":"Git Pull Request Hygiene"}]},{"@type":"WebSite","@id":"https:\/\/demo.sidekick.be\/itenium\/#website","url":"https:\/\/demo.sidekick.be\/itenium\/","name":"Itenium","description":"We build software. We build careers.","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/demo.sidekick.be\/itenium\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/demo.sidekick.be\/itenium\/#\/schema\/person\/6ab401ce01e858184ee4a8667fe0f022","name":"Usdevelop","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/demo.sidekick.be\/itenium\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/cc8cf9b9e9d5bbe7e8d247907cc9ac8457bbfa2854b52eaddf6529adfe88ceab?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/cc8cf9b9e9d5bbe7e8d247907cc9ac8457bbfa2854b52eaddf6529adfe88ceab?s=96&d=mm&r=g","caption":"Usdevelop"},"sameAs":["https:\/\/demo.sidekick.be\/itenium"]}]}},"_links":{"self":[{"href":"https:\/\/demo.sidekick.be\/itenium\/wp-json\/wp\/v2\/posts\/1415","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/demo.sidekick.be\/itenium\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/demo.sidekick.be\/itenium\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/demo.sidekick.be\/itenium\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/demo.sidekick.be\/itenium\/wp-json\/wp\/v2\/comments?post=1415"}],"version-history":[{"count":3,"href":"https:\/\/demo.sidekick.be\/itenium\/wp-json\/wp\/v2\/posts\/1415\/revisions"}],"predecessor-version":[{"id":2262,"href":"https:\/\/demo.sidekick.be\/itenium\/wp-json\/wp\/v2\/posts\/1415\/revisions\/2262"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/demo.sidekick.be\/itenium\/wp-json\/wp\/v2\/media\/1993"}],"wp:attachment":[{"href":"https:\/\/demo.sidekick.be\/itenium\/wp-json\/wp\/v2\/media?parent=1415"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/demo.sidekick.be\/itenium\/wp-json\/wp\/v2\/categories?post=1415"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/demo.sidekick.be\/itenium\/wp-json\/wp\/v2\/tags?post=1415"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}