{"id":4244,"date":"2026-02-26T11:04:32","date_gmt":"2026-02-26T10:04:32","guid":{"rendered":"https:\/\/nguenkam.com\/blog\/?p=4244"},"modified":"2026-02-26T11:04:32","modified_gmt":"2026-02-26T10:04:32","slug":"usefull-git-config-settings","status":"publish","type":"post","link":"https:\/\/nguenkam.com\/blog\/index.php\/2026\/02\/26\/usefull-git-config-settings\/","title":{"rendered":"Usefull Git Config Settings"},"content":{"rendered":"\n

git config<\/code> is the command used to read and write Git settings<\/strong>\u2014preferences that control how Git behaves for everyday operations like pull<\/code>, push<\/code>, fetch<\/code>, diff<\/code>, merges, and rebases.<\/p>\n\n\n\n

Using git config<\/code> turns repeated \u201cremember to pass this flag\u201d habits into defaults<\/strong>, so your workflow becomes faster, more consistent, and less error-prone.<\/p>\n\n\n\n

What git config<\/code> does<\/h4>\n\n\n\n

git config<\/code> stores key\/value settings in Git\u2019s configuration files. You typically set them at one of these levels:<\/p>\n\n\n\n

  • Global<\/strong> (--global<\/code>): applies to all repositories for your user<\/li>
  • Local<\/strong> (repository-only): applies just to the current repo<\/li><\/ul>\n\n\n\n

    Inspect what you have:<\/p>\n\n\n\n

    \/\/ check all the available options\ngit config --global --list\n\n\/\/or check a single option\ngit config --global pull.rebase<\/code><\/pre>\n\n\n\n
    With git config<\/code>, you make Git do the sensible thing by default<\/strong>, every time.<\/p>\n\n\n\n
    Few high-impact\u00a0git config<\/code>\u00a0settings (what they do + what happens without them)<\/h4>\n\n\n\n
    1) Rebase on pull (instead of merge)<\/strong><\/span><\/h4>\n\n\n\n
    git config --global pull.rebase true\r<\/code><\/pre>\n\n\n\n
    What it does<\/h5>\n\n\n\n
    When we run git pull<\/code>, Git integrates upstream changes using rebase<\/strong>, replaying our local commits on top of the updated base, rather than creating a merge commit.<\/p>\n\n\n\n
    Advantage<\/h5>\n\n\n\n
    • a cleaner, more linear history<\/li>
    • fewer \u201cMerge branch \u2026\u201d commits that add little value<\/li>
    • git log<\/code> reads like a timeline<\/li><\/ul>\n\n\n\n
      What happens without it<\/strong><\/span><\/h5>\n\n\n\n
      A normal git pull<\/code> can create merge commits<\/strong> when your branch and the remote have diverged\u2014leading to a cluttered history.<\/p>\n\n\n\n
      Without (typical outcome):<\/span><\/strong><\/p>\n\n\n\n
      git checkout feature\/login\r\ngit pull\r\n# Often results in a merge commit on your feature branch\r<\/code><\/pre>\n\n\n\n
      With rebase enabled:<\/strong><\/p>\n\n\n\n
      git checkout feature\/login\r\ngit pull\r\n# Your commits are replayed on top of the latest upstream commits\r<\/code><\/pre>\n\n\n\n
      PS:<\/span><\/strong>  rebasing rewrites commit IDs. It\u2019s usually great for local feature branches, but be careful rebasing shared branches others are already using.<\/em><\/p>\n\n\n\n
      2) Automatically set upstream on first push<\/strong><\/span><\/h4>\n\n\n\n
      git config --global push.autoSetupRemote true\r<\/code><\/pre>\n\n\n\n
      What it does<\/h5>\n\n\n\n
      When we push a new branch<\/strong> for the first time, Git automatically sets the upstream tracking branch (e.g., origin\/my-branch<\/code>).<\/p>\n\n\n\n
      Advantage<\/h5>\n\n\n\n
      • first push is just git push<\/code><\/li>
      • future git push<\/code>\/git pull<\/code> work without extra arguments<\/li><\/ul>\n\n\n\n
        What happens without it<\/strong><\/span><\/h5>\n\n\n\n
        You often see this error on first push:<\/p>\n\n\n\n
        fatal: The current branch my-branch has no upstream branch.\n\n\/\/Then we must run:\n\/\/ git push --set-upstream origin my-branch\r\n\r<\/code><\/pre>\n\n\n\n
        With the setting:<\/span><\/strong><\/h5>\n\n\n\n
        git checkout -b feature\/search\r\ngit push\r\n# Upstream is configured automatically\r<\/code><\/pre>\n\n\n\n
        3) Auto-prune deleted remote branches on fetch<\/strong><\/span><\/h4>\n\n\n\n
        git config --global fetch.prune true\r<\/code><\/pre>\n\n\n\n
        What it does<\/h5>\n\n\n\n
        When remote branches are deleted (after merge, cleanup, etc.), Git removes the stale remote-tracking references automatically during fetch<\/code>.<\/p>\n\n\n\n
        Advantage<\/h5>\n\n\n\n
        • git branch -r<\/code> reflects what actually exists on the remote<\/li>
        • less confusion and fewer \u201cghost branches\u201d<\/li><\/ul>\n\n\n\n
          What happens without it<\/strong><\/span><\/h5>\n\n\n\n
          Old remote-tracking references linger locally:<\/p>\n\n\n\n
          git fetch\r\ngit branch -r\r\n# Still shows origin\/feature\/old-branch even if it was deleted remotely\n\n\n\/\/You then need to manually prune:\n\/\/git remote prune origin\r\n\r<\/code><\/pre>\n\n\n\n
          With fetch.prune=true<\/code>, pruning happens automatically.<\/p>\n\n\n\n
          4) Use a better diff algorithm (histogram)<\/strong><\/span><\/h4>\n\n\n\n
          git config --global diff.algorithm histogram\r<\/code><\/pre>\n\n\n\n
          What it does<\/h5>\n\n\n\n
          Switches Git\u2019s diff algorithm to histogram<\/code>, which often produces cleaner, more readable diffs<\/strong> for code with many similar lines (repeated braces, returns, similar blocks).<\/p>\n\n\n\n
          Advantage<\/h5>\n\n\n\n
          • easier code reviews<\/li>
          • diffs better reflect \u201cwhat really changed\u201d (less noisy add\/remove churn)<\/li><\/ul>\n\n\n\n
            What happens without it<\/strong><\/span><\/h5>\n\n\n\n
            The default algorithm can \u201cmatch\u201d similar lines in a way that makes diffs look messy\u2014especially in refactors\u2014so reviewers may struggle to see the true intent.<\/p>\n\n\n\n
            5) Reuse recorded conflict resolutions (rerere<\/code>)<\/strong><\/span><\/h4>\n\n\n\n
            git config --global rerere.enabled true\r<\/code><\/pre>\n\n\n\n
            What it does<\/h5>\n\n\n\n
            rerere<\/code> (\u201creuse recorded resolution\u201d) records how you resolved a conflict. If the same<\/em> conflict appears again (common during repeated rebases\/merges of a long-lived branch), Git can apply your previous resolution automatically\u2014still leaving you able to review the result.<\/p>\n\n\n\n
            Advantage<\/h5>\n\n\n\n
            • huge time saver for long-running branches<\/li>
            • fewer repeated manual conflict fixes<\/li>
            • less fatigue and fewer mistakes during rebases<\/li><\/ul>\n\n\n\n
              What happens without it<\/strong><\/span><\/h5>\n\n\n\n
              You may fix the same conflict repeatedly:<\/p>\n\n\n\n
              1. Rebase ? conflict in file X<\/li>
              2. You resolve it manually<\/li>
              3. Rebase again next week ? same conflict<\/li>
              4. You resolve it manually again<\/li><\/ol>\n\n\n\n
                With rerere<\/code>, step 4 often becomes \u201cverify\u201d rather than \u201credo\u201d.<\/p>\n","protected":false},"excerpt":{"rendered":"
                git config is the command used to read and write Git settings\u2014preferences that control how Git behaves for everyday operations like pull, push, fetch, diff, merges, and rebases. Using git config turns repeated \u201cremember to pass this flag\u201d habits into defaults, so your workflow becomes faster, more consistent, and less error-prone. What git config does git config […]<\/p>\n","protected":false},"author":1,"featured_media":807,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1,60],"tags":[1127,1126,1125,1124,494],"_links":{"self":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/4244"}],"collection":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=4244"}],"version-history":[{"count":2,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/4244\/revisions"}],"predecessor-version":[{"id":4246,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/4244\/revisions\/4246"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/media\/807"}],"wp:attachment":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=4244"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=4244"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=4244"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}