{"id":1607,"date":"2023-08-15T16:40:12","date_gmt":"2023-08-15T16:40:12","guid":{"rendered":"https:\/\/www.aviator.co\/blog\/?p=1607"},"modified":"2025-10-23T15:20:10","modified_gmt":"2025-10-23T15:20:10","slug":"how-git-compresses-files","status":"publish","type":"post","link":"https:\/\/www.aviator.co\/blog\/how-git-compresses-files\/","title":{"rendered":"How Git Compresses Files"},"content":{"rendered":"\n<p>Git stores the files efficiently by only storing the differences, but how does it actually work? Naively, we can think of the&nbsp;<code>git diff<\/code>&nbsp;output and storing it. <\/p>\n\n\n\n<p>This is not the case. Let&#8217;s look at how things actually work.<\/p>\n\n\n\n<figure class=\"wp-block-image aligncenter size-large\"><img fetchpriority=\"high\" decoding=\"async\" width=\"1024\" height=\"580\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-12.36.08-PM-1024x580.jpg\" alt=\"\" class=\"wp-image-1613\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-12.36.08-PM-1024x580.jpg 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-12.36.08-PM-300x170.jpg 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-12.36.08-PM-768x435.jpg 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-12.36.08-PM-1536x869.jpg 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-12.36.08-PM.jpg 1636w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">TL;DR<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Git compresses files efficiently using <em>delta compression<\/em>, storing only differences between file versions instead of full copies.<\/li>\n\n\n\n<li>It creates \u201ccopy\u201d and \u201cwrite\u201d command sequences (deltas) using a rolling hash algorithm to detect similar chunks between versions.<\/li>\n\n\n\n<li>For multiple files, Git uses heuristics like file name similarity, growth trends, and access frequency to decide which files to delta-compress.<\/li>\n\n\n\n<li>Compression favors keeping newer files as full copies, using older ones as deltas, and maintaining shallow delta chains for faster access.<\/li>\n\n\n\n<li>These compression insights also apply to caching and data storage systems beyond Git.<\/li>\n\n\n\n<li>Aviator automates Git workflows through MergeQueue, ChangeSets, TestDeck, and Stacked PRs CLI to streamline development and testing.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"compressing-one-file\"><strong><strong>Compressing One File<\/strong><\/strong><\/h2>\n\n\n\n<p>Let\u2019s start with a simple scenario; there is only one file in the repository. We modify that file and make a commit. Now there are the current and previous versions of that file. If we were a Git-core developer, how can we store these two versions of a file efficiently?<\/p>\n\n\n\n<p>A naive approach is taking a&nbsp;<code>diff<\/code>&nbsp;of these two files. If we keep a full copy of the file v1 and a&nbsp;<code>diff<\/code>&nbsp;output between the file v1 and the v2, we do not need a full copy of the file v2. In order to rebuild the file v2, we can apply the patch to the file v1.<\/p>\n\n\n\n<figure class=\"wp-block-image aligncenter size-full\"><img decoding=\"async\" width=\"1024\" height=\"402\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.00-AM.png\" alt=\"\" class=\"wp-image-1608\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.00-AM.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.00-AM-300x118.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.00-AM-768x302.png 768w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>This works, and it is conceptually what Git does. However, Git is not simply using the&nbsp;<code>diff<\/code>&nbsp;command to calculate the diffs.<\/p>\n\n\n\n<p>Instead of using the&nbsp;<code>diff<\/code>&nbsp;output, Git has its own format. This format is a sequence of two commands:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Copy: Takes an offset and a length. Copies a byte sequence from the file v1 at the specified offset<\/li>\n\n\n\n<li>Write: Takes a byte sequence. Insert the specified sequence<\/li>\n<\/ul>\n\n\n\n<p>This command sequence is instructions on how to recreate the file v2. Given the file v1, if you follow these commands, you can get the file v2. This is well explained and visualized in the GitHub blog (<a href=\"https:\/\/github.blog\/2022-08-29-gits-database-internals-i-packed-object-store\/#delta-compression\">https:\/\/github.blog\/2022-08-29-gits-database-internals-i-packed-object-store\/#delta-compression<\/a>).<\/p>\n\n\n\n<p>Now the question is how to create this sequence from the file v1 and v2. Git uses the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Rolling_hash\">rolling hash<\/a> to find out the similarity.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Split the file v1 into small chunks, and take a hash of them. You can construct<code>&nbsp;Map&lt;HashCode, List&lt;Offset&gt;&gt;<\/code>,  where the key is the calculated hash and the value is a list of the file offset of the chunks with that hash code.<\/li>\n\n\n\n<li>Read the file v2 from the beginning. Take the same-sized chunk and hash it. With the table created in the previous step, you can get the file v1\u2019s offsets that can have the same chunk. You can go over those offsets, and find the longest common sequence between this file v1 and v2 for this portion of the file. Output the copy command to the diffing output. If you cannot find a common sequence, you can use the write command, and continue to the next byte.<\/li>\n<\/ol>\n\n\n\n<figure class=\"wp-block-image aligncenter size-large\"><img decoding=\"async\" width=\"1024\" height=\"526\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.18-AM-1024x526.png\" alt=\"\" class=\"wp-image-1609\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.18-AM-1024x526.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.18-AM-300x154.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.18-AM-768x395.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.18-AM.png 1288w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>This algorithm is similar to the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Rabin%E2%80%93Karp_algorithm\">Rabin-Karp algorithm<\/a>, but the hash is used for finding a common sequence. In Git, instead of \u201cdiff\u201d, we call this copy\/write command sequence as \u201cdelta\u201d.<\/p>\n\n\n\n<p>You can find the file v1\u2019s indexing code in Git\u2019s create_delta_index (<a href=\"https:\/\/github.com\/git\/git\/blob\/aa9166bcc0ba654fc21f198a30647ec087f733ed\/diff-delta.c#L133\">https:\/\/github.com\/git\/git\/blob\/aa9166bcc0ba654fc21f198a30647ec087f733ed\/diff-delta.c#L133<\/a>), file v2 compression code in create_delta (<a href=\"https:\/\/github.com\/git\/git\/blob\/aa9166bcc0ba654fc21f198a30647ec087f733ed\/diff-delta.c#L318\">https:\/\/github.com\/git\/git\/blob\/aa9166bcc0ba654fc21f198a30647ec087f733ed\/diff-delta.c#L318<\/a>), and the file v2 rebuilding code in patch_delta (<a href=\"https:\/\/github.com\/git\/git\/blob\/aa9166bcc0ba654fc21f198a30647ec087f733ed\/patch-delta.c#L15\">https:\/\/github.com\/git\/git\/blob\/aa9166bcc0ba654fc21f198a30647ec087f733ed\/patch-delta.c#L15<\/a>).<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><a href=\"https:\/\/docs.aviator.co\/mergequeue\" target=\"_blank\" rel=\" noreferrer noopener\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"264\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/04\/aviator-mergequeue-blog-documentation-cta-photo-min-1-1024x264.png\" alt=\"MergeQueue CTA\" class=\"wp-image-4921\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/04\/aviator-mergequeue-blog-documentation-cta-photo-min-1-1024x264.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/04\/aviator-mergequeue-blog-documentation-cta-photo-min-1-300x77.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/04\/aviator-mergequeue-blog-documentation-cta-photo-min-1-768x198.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/04\/aviator-mergequeue-blog-documentation-cta-photo-min-1-1536x396.png 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2024\/04\/aviator-mergequeue-blog-documentation-cta-photo-min-1.png 1940w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/a><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"compressing-more-than-one-file\"><strong>Compressing More Than One File<\/strong><\/h2>\n\n\n\n<p>With the rolling hash method, we have&nbsp;<code>delta = create_delta(file1, file2)<\/code>&nbsp;and&nbsp;<code>file2 = apply_delta(file1, delta)<\/code>. Now the question is how can we find such&nbsp;<code>file1<\/code>&nbsp;and&nbsp;<code>file2<\/code>&nbsp;pairs that compress well.<\/p>\n\n\n\n<p>If we have unlimited compute resources, we can try all pairs in the repository, but we don\u2019t. We need to use heuristics here. As we saw earlier, the delta only contains two kinds of commands: copy and write, and in order to minimize the delta, it\u2019s better to have more copy commands instead of using write commands. Hence, finding similar files should result in better compression.<\/p>\n\n\n\n<p>Intuitively, we can think that&nbsp;<code>src\/MyClass.java<\/code>&nbsp;is similar to its past versions than other files. Git is using such heuristics to find the&nbsp;<code>file1<\/code>&nbsp;and&nbsp;<code>file2<\/code>&nbsp;pairs. This is explained in Git\u2019s pack-heuristics documentation (<a href=\"https:\/\/git-scm.com\/docs\/pack-heuristics\">https:\/\/git-scm.com\/docs\/pack-heuristics<\/a>). These are the highlights of these heuristics:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Same-name files are similar<\/li>\n\n\n\n<li>Files grow over time<\/li>\n\n\n\n<li>Latest versions are more accessed than older versions<\/li>\n\n\n\n<li>Keep the deltas shallow<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"same-name-files-are-similar\"><strong>Same-Name Files Are Similar<\/strong><\/h2>\n\n\n\n<p>This looks obvious, but the same file\u2019s v1 and v2 are very similar and well-compressed. Git does not only that but also it tries to find the same name files in a different directory.<\/p>\n\n\n\n<p>When a file is moved to a different directory and the file name is the same, this allows Git to compress the files even before and after the file move. Also, if you need to put a configuration file for every directory, such as the&nbsp;<code>BUILD<\/code>&nbsp;file in Bazel, those files might have a similarity.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"files-grow-over-time\"><strong>Files Grow Over Time<\/strong><\/h2>\n\n\n\n<p>In general, file and repository sizes get larger as the development continues. You might be proud of deleting more lines than adding, but the general tendency is that the software gets more features and gets more lines.<\/p>\n\n\n\n<p>This insight gives us an interesting approach. It\u2019s better to take a delta from the new version to the old version instead of the other way around. Since we as software engineers modify the file v1 and create a new version, we feel like the file v2 is built on top of the file v1. This is true with the diff output. If you run&nbsp;<code>git diff<\/code>, it shows how to create v2 from v1. <\/p>\n\n\n\n<p>However, remember that Git delta compression only has copy and write commands. Adding something to the base file needs more cost than removing something. Removing some data from a file is just a matter of not copying that portion.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"254\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.28-AM-1024x254.png\" alt=\"\" class=\"wp-image-1610\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.28-AM-1024x254.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.28-AM-300x74.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.28-AM-768x190.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.28-AM.png 1438w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>If files grow over time, then it\u2019s better to create a delta from the latest version to old versions for better compression. This is a good bookkeeping task. As you write more code, you will make forward deltas (v1 to v2 deltas), and by running re-deltification, you can make them reverse deltas (v2 to v1 deltas) that provide better compression.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"latest-versions-are-more-accessed-than-older-versions\"><strong>The Latest Versions Are Accessed More Frequently Than Older Versions<\/strong><\/h2>\n\n\n\n<p>With Git delta compression, you have one full copy and one delta. In order to read the deltified version, you need to apply the delta to the full copy version. This means that accessing the deltified files needs some computational cost.<\/p>\n\n\n\n<p>Having this in mind, when we get to choose which file to be the full copy, it\u2019s better to choose the recent files than older files. This is because recent versions tend to be accessed more frequently than older versions. When cloning a repository, when creating a new topic branch, and when cutting a new release, we check out the recent version.<\/p>\n\n\n\n<p>This is in line with the previous file size growth insight. Recent files tend to have a larger file size, so keeping the latest version as the full copy and deltifing the old versions makes sense from both aspects.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"keep-the-deltas-shallow\"><strong>Keep the Deltas Shallow<\/strong><\/h2>\n\n\n\n<p>The compression can be chained. For example, you can keep the file v5 and delta-compress the v4, then you can delta-compress v3 against v4, v2 against v3, and so on. If you do this, in order to read the file v1, you need to delta-uncompress v4, v3, v2, and v1. This needs unnecessary cost. Instead, you can delta-compress v1 through v4 against v5, and keep the delta chain shallow.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"434\" src=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.40-AM-1024x434.png\" alt=\"\" class=\"wp-image-1611\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.40-AM-1024x434.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.40-AM-300x127.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.40-AM-768x325.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-11.39.40-AM.png 1416w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n\n\n\n<p>This way, you only need to delta-uncompress once to access v1.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" id=\"summary\">Summary<\/h2>\n\n\n\n<p>In the article, we saw how Git compresses files using a rolling hash and the heuristics it uses to pick files to compress. Both of them come with great insights. The rolling hash has more applications such as documentation similarities. <\/p>\n\n\n\n<p>The file recency and locality insights can be applicable to other caching systems. While Git\u2019s file compression is a subtle topic and invisible to users, it is interesting to dive into.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">FAQs<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Does Git Compress Files?<\/h3>\n\n\n\n<p>Yes, Git compresses files using the <strong>zlib<\/strong> compression algorithm to efficiently store data in its repository. This helps reduce storage space and speeds up data transfer when cloning or fetching repositories.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How Do I Remove Cached Files?<\/h3>\n\n\n\n<p>You can remove cached files in Git using the command <strong><code>git rm --cached &lt;filename&gt;<\/code><\/strong>. This removes the file from the Git index (staging area) but keeps it in your working directory, allowing you to stop tracking it without deleting it locally.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Does Git Compress Database?<\/h3>\n\n\n\n<p>Git doesn\u2019t use a traditional database but stores data in its <strong>.git<\/strong> directory as objects. These objects, commits, trees, and blobs and are compressed using <strong>zlib<\/strong>, so in essence, Git compresses its internal data storage rather than a database.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is It Good to Compress Files?<\/h3>\n\n\n\n<p>Yes, compressing files is generally beneficial because it saves disk space and speeds up transfers. However, excessive compression can slow down performance during read\/write operations, so it\u2019s best used where space or bandwidth efficiency matters most.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><a href=\"https:\/\/www.aviator.co\/\" target=\"_blank\" rel=\"noreferrer noopener\">Aviator<\/a>: <strong>Automate Your Cumbersome Processes<\/strong><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><a href=\"https:\/\/www.aviator.co\/\" target=\"_blank\" rel=\"noreferrer noopener\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"727\" src=\"https:\/\/blog.aviator.co\/wp-content\/uploads\/2022\/08\/blog-cta-1024x727.png\" alt=\"\" class=\"wp-image-57\" srcset=\"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2022\/08\/blog-cta-1024x727.png 1024w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2022\/08\/blog-cta-300x213.png 300w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2022\/08\/blog-cta-768x545.png 768w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2022\/08\/blog-cta-1536x1090.png 1536w, https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2022\/08\/blog-cta-2048x1454.png 2048w\" sizes=\"(max-width: 1024px) 100vw, 1024px\" \/><\/a><\/figure>\n\n\n\n<p>Aviator automates tedious developer workflows by managing git Pull Requests (PRs) and continuous integration test (CI) runs to help your team avoid broken builds, streamline cumbersome merge processes, manage cross-PR dependencies, and handle flaky tests while maintaining their security compliance.<\/p>\n\n\n\n<p>There are 4 key components to Aviator:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>MergeQueue<\/strong>&nbsp;\u2013 an automated queue that manages the merging workflow for your GitHub repository to help protect important branches from broken builds. The Aviator bot uses GitHub Labels to identify Pull Requests (PRs) that are ready to be merged, validates CI checks, processes semantic conflicts, and merges the PRs automatically.<\/li>\n\n\n\n<li><strong>ChangeSets<\/strong>&nbsp;\u2013 workflows to synchronize validating and merging multiple PRs within the same repository or multiple repositories. Useful when your team often sees groups of related PRs that need to be merged together, or otherwise treated as a single broader unit of change.<\/li>\n\n\n\n<li><strong>TestDeck<\/strong>&nbsp;\u2013 a tool to automatically detect, take action on, and process results from flaky tests in your CI infrastructure.<\/li>\n\n\n\n<li><strong>Stacked PRs CLI<\/strong>&nbsp;\u2013 a command line tool that helps developers manage cross-PR dependencies. This tool also automates syncing and merging of stacked PRs. Useful when your team wants to promote a culture of smaller, incremental PRs instead of large changes, or when your workflows involve keeping multiple, dependent PRs in sync.<\/li>\n<\/ol>\n\n\n\n<p><a href=\"https:\/\/www.aviator.co\/\" target=\"_blank\" rel=\"noopener\" title=\"\">Try it for free.<\/a><\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>In this article, we will dive into the Git internals and see how files are actually compressed and stored there.<\/p>\n","protected":false},"author":20,"featured_media":1613,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[301],"tags":[],"class_list":["post-1607","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tutorials-guides"],"blocksy_meta":{"styles_descriptor":{"styles":{"desktop":"","tablet":"","mobile":""},"google_fonts":[],"version":6}},"acf":[],"aioseo_notices":[],"jetpack_featured_media_url":"https:\/\/www.aviator.co\/blog\/wp-content\/uploads\/2023\/08\/Screenshot-2023-08-15-at-12.36.08-PM.jpg","post_mailing_queue_ids":[],"_links":{"self":[{"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/posts\/1607","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/users\/20"}],"replies":[{"embeddable":true,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/comments?post=1607"}],"version-history":[{"count":9,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/posts\/1607\/revisions"}],"predecessor-version":[{"id":5122,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/posts\/1607\/revisions\/5122"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/media\/1613"}],"wp:attachment":[{"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/media?parent=1607"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/categories?post=1607"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.aviator.co\/blog\/wp-json\/wp\/v2\/tags?post=1607"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}