{
    "mode": "man",
    "parameter": "GITFAQ",
    "section": "7",
    "url": "https://www.chedong.com/phpMan.php/man/GITFAQ/7/json",
    "generated": "2026-05-30T06:05:26Z",
    "synopsis": "gitfaq",
    "sections": {
        "NAME": {
            "content": "gitfaq - Frequently asked questions about using Git\n",
            "subsections": []
        },
        "SYNOPSIS": {
            "content": "gitfaq\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "The examples in this FAQ assume a standard POSIX shell, like bash or dash, and a user, A U\nThor, who has the account author on the hosting provider git.example.org.\n",
            "subsections": []
        },
        "CONFIGURATION": {
            "content": "What should I put in user.name?\nYou should put your personal name, generally a form using a given name and family name.\nFor example, the current maintainer of Git uses \"Junio C Hamano\". This will be the name\nportion that is stored in every commit you make.\n\nThis configuration doesn’t have any effect on authenticating to remote services; for\nthat, see credential.username in git-config(1).\n\nWhat does http.postBuffer really do?\nThis option changes the size of the buffer that Git uses when pushing data to a remote\nover HTTP or HTTPS. If the data is larger than this size, libcurl, which handles the HTTP\nsupport for Git, will use chunked transfer encoding since it isn’t known ahead of time\nwhat the size of the pushed data will be.\n\nLeaving this value at the default size is fine unless you know that either the remote\nserver or a proxy in the middle doesn’t support HTTP/1.1 (which introduced the chunked\ntransfer encoding) or is known to be broken with chunked data. This is often\n(erroneously) suggested as a solution for generic push problems, but since almost every\nserver and proxy supports at least HTTP/1.1, raising this value usually doesn’t solve\nmost push problems. A server or proxy that didn’t correctly support HTTP/1.1 and chunked\ntransfer encoding wouldn’t be that useful on the Internet today, since it would break\nlots of traffic.\n\nNote that increasing this value will increase the memory used on every relevant push that\nGit does over HTTP or HTTPS, since the entire buffer is allocated regardless of whether\nor not it is all used. Thus, it’s best to leave it at the default unless you are sure you\nneed a different value.\n\nHow do I configure a different editor?\nIf you haven’t specified an editor specifically for Git, it will by default use the\neditor you’ve configured using the VISUAL or EDITOR environment variables, or if neither\nis specified, the system default (which is usually vi). Since some people find vi\ndifficult to use or prefer a different editor, it may be desirable to change the editor\nused.\n\nIf you want to configure a general editor for most programs which need one, you can edit\nyour shell configuration (e.g., ~/.bashrc or ~/.zshenv) to contain a line setting the\nEDITOR or VISUAL environment variable to an appropriate value. For example, if you prefer\nthe editor nano, then you could write the following:\n\nexport VISUAL=nano\n\nIf you want to configure an editor specifically for Git, you can either set the\ncore.editor configuration value or the GITEDITOR environment variable. You can see git-\nvar(1) for details on the order in which these options are consulted.\n\nNote that in all cases, the editor value will be passed to the shell, so any arguments\ncontaining spaces should be appropriately quoted. Additionally, if your editor normally\ndetaches from the terminal when invoked, you should specify it with an argument that\nmakes it not do that, or else Git will not see any changes. An example of a configuration\naddressing both of these issues on Windows would be the configuration \"C:\\Program\nFiles\\Vim\\gvim.exe\" --nofork, which quotes the filename with spaces and specifies the\n--nofork option to avoid backgrounding the process.\n",
            "subsections": []
        },
        "CREDENTIALS": {
            "content": "How do I specify my credentials when pushing over HTTP?\nThe easiest way to do this is to use a credential helper via the credential.helper\nconfiguration. Most systems provide a standard choice to integrate with the system\ncredential manager. For example, Git for Windows provides the wincred credential manager,\nmacOS has the osxkeychain credential manager, and Unix systems with a standard desktop\nenvironment can use the libsecret credential manager. All of these store credentials in\nan encrypted store to keep your passwords or tokens secure.\n\nIn addition, you can use the store credential manager which stores in a file in your home\ndirectory, or the cache credential manager, which does not permanently store your\ncredentials, but does prevent you from being prompted for them for a certain period of\ntime.\n\nYou can also just enter your password when prompted. While it is possible to place the\npassword (which must be percent-encoded) in the URL, this is not particularly secure and\ncan lead to accidental exposure of credentials, so it is not recommended.\n\nHow do I read a password or token from an environment variable?\nThe credential.helper configuration option can also take an arbitrary shell command that\nproduces the credential protocol on standard output. This is useful when passing\ncredentials into a container, for example.\n\nSuch a shell command can be specified by starting the option value with an exclamation\npoint. If your password or token were stored in the GITTOKEN, you could run the\nfollowing command to set your credential helper:\n\n$ git config credential.helper \\\n'!f() { echo username=author; echo \"password=$GITTOKEN\"; };f'\n\n\nHow do I change the password or token I’ve saved in my credential manager?\nUsually, if the password or token is invalid, Git will erase it and prompt for a new one.\nHowever, there are times when this doesn’t always happen. To change the password or\ntoken, you can erase the existing credentials and then Git will prompt for new ones. To\nerase credentials, use a syntax like the following (substituting your username and the\nhostname):\n\n$ echo url=https://author@git.example.org | git credential reject\n\n\nHow do I use multiple accounts with the same hosting provider using HTTP?\nUsually the easiest way to distinguish between these accounts is to use the username in\nthe URL. For example, if you have the accounts author and committer on git.example.org,\nyou can use the URLs https://author@git.example.org/org1/project1.git and\nhttps://committer@git.example.org/org2/project2.git. This way, when you use a credential\nhelper, it will automatically try to look up the correct credentials for your account. If\nyou already have a remote set up, you can change the URL with something like git remote\nset-url origin https://author@git.example.org/org1/project1.git (see git-remote(1) for\ndetails).\n\nHow do I use multiple accounts with the same hosting provider using SSH?\nWith most hosting providers that support SSH, a single key pair uniquely identifies a\nuser. Therefore, to use multiple accounts, it’s necessary to create a key pair for each\naccount. If you’re using a reasonably modern OpenSSH version, you can create a new key\npair with something like ssh-keygen -t ed25519 -f ~/.ssh/idcommitter. You can then\nregister the public key (in this case, ~/.ssh/idcommitter.pub; note the .pub) with the\nhosting provider.\n\nMost hosting providers use a single SSH account for pushing; that is, all users push to\nthe git account (e.g., git@git.example.org). If that’s the case for your provider, you\ncan set up multiple aliases in SSH to make it clear which key pair to use. For example,\nyou could write something like the following in ~/.ssh/config, substituting the proper\nprivate key file:\n\n# This is the account for author on git.example.org.\nHost exampleauthor\nHostName git.example.org\nUser git\n# This is the key pair registered for author with git.example.org.\nIdentityFile ~/.ssh/idauthor\nIdentitiesOnly yes\n# This is the account for committer on git.example.org.\nHost examplecommitter\nHostName git.example.org\nUser git\n# This is the key pair registered for committer with git.example.org.\nIdentityFile ~/.ssh/idcommitter\nIdentitiesOnly yes\n\nThen, you can adjust your push URL to use git@exampleauthor or git@examplecommitter\ninstead of git@example.org (e.g., git remote set-url\ngit@exampleauthor:org1/project1.git).\n",
            "subsections": []
        },
        "COMMON ISSUES": {
            "content": "I’ve made a mistake in the last commit. How do I change it?\nYou can make the appropriate change to your working tree, run git add <file> or git rm\n<file>, as appropriate, to stage it, and then git commit --amend. Your change will be\nincluded in the commit, and you’ll be prompted to edit the commit message again; if you\nwish to use the original message verbatim, you can use the --no-edit option to git commit\nin addition, or just save and quit when your editor opens.\n\nI’ve made a change with a bug and it’s been included in the main branch. How should I undo\nit?\nThe usual way to deal with this is to use git revert. This preserves the history that the\noriginal change was made and was a valuable contribution, but also introduces a new\ncommit that undoes those changes because the original had a problem. The commit message\nof the revert indicates the commit which was reverted and is usually edited to include an\nexplanation as to why the revert was made.\n\nHow do I ignore changes to a tracked file?\nGit doesn’t provide a way to do this. The reason is that if Git needs to overwrite this\nfile, such as during a checkout, it doesn’t know whether the changes to the file are\nprecious and should be kept, or whether they are irrelevant and can safely be destroyed.\nTherefore, it has to take the safe route and always preserve them.\n\nIt’s tempting to try to use certain features of git update-index, namely the\nassume-unchanged and skip-worktree bits, but these don’t work properly for this purpose\nand shouldn’t be used this way.\n\nIf your goal is to modify a configuration file, it can often be helpful to have a file\nchecked into the repository which is a template or set of defaults which can then be\ncopied alongside and modified as appropriate. This second, modified file is usually\nignored to prevent accidentally committing it.\n\nI asked Git to ignore various files, yet they are still tracked\nA gitignore file ensures that certain file(s) which are not tracked by Git remain\nuntracked. However, sometimes particular file(s) may have been tracked before adding them\ninto the .gitignore, hence they still remain tracked. To untrack and ignore\nfiles/patterns, use git rm --cached <file/pattern> and add a pattern to .gitignore that\nmatches the <file>. See gitignore(5) for details.\n\nHow do I know if I want to do a fetch or a pull?\nA fetch stores a copy of the latest changes from the remote repository, without modifying\nthe working tree or current branch. You can then at your leisure inspect, merge, rebase\non top of, or ignore the upstream changes. A pull consists of a fetch followed\nimmediately by either a merge or rebase. See git-pull(1).\n",
            "subsections": []
        },
        "MERGING AND REBASING": {
            "content": "What kinds of problems can occur when merging long-lived branches with squash merges?\nIn general, there are a variety of problems that can occur when using squash merges to\nmerge two branches multiple times. These can include seeing extra commits in git log\noutput, with a GUI, or when using the ...  notation to express a range, as well as the\npossibility of needing to re-resolve conflicts again and again.\n\nWhen Git does a normal merge between two branches, it considers exactly three points: the\ntwo branches and a third commit, called the merge base, which is usually the common\nancestor of the commits. The result of the merge is the sum of the changes between the\nmerge base and each head. When you merge two branches with a regular merge commit, this\nresults in a new commit which will end up as a merge base when they’re merged again,\nbecause there is now a new common ancestor. Git doesn’t have to consider changes that\noccurred before the merge base, so you don’t have to re-resolve any conflicts you\nresolved before.\n\nWhen you perform a squash merge, a merge commit isn’t created; instead, the changes from\none side are applied as a regular commit to the other side. This means that the merge\nbase for these branches won’t have changed, and so when Git goes to perform its next\nmerge, it considers all of the changes that it considered the last time plus the new\nchanges. That means any conflicts may need to be re-resolved. Similarly, anything using\nthe ...  notation in git diff, git log, or a GUI will result in showing all of the\nchanges since the original merge base.\n\nAs a consequence, if you want to merge two long-lived branches repeatedly, it’s best to\nalways use a regular merge commit.\n\nIf I make a change on two branches but revert it on one, why does the merge of those branches\ninclude the change?\nBy default, when Git does a merge, it uses a strategy called the ort strategy, which does\na fancy three-way merge. In such a case, when Git performs the merge, it considers\nexactly three points: the two heads and a third point, called the merge base, which is\nusually the common ancestor of those commits. Git does not consider the history or the\nindividual commits that have happened on those branches at all.\n\nAs a result, if both sides have a change and one side has reverted that change, the\nresult is to include the change. This is because the code has changed on one side and\nthere is no net change on the other, and in this scenario, Git adopts the change.\n\nIf this is a problem for you, you can do a rebase instead, rebasing the branch with the\nrevert onto the other branch. A rebase in this scenario will revert the change, because a\nrebase applies each individual commit, including the revert. Note that rebases rewrite\nhistory, so you should avoid rebasing published branches unless you’re sure you’re\ncomfortable with that. See the NOTES section in git-rebase(1) for more details.\n",
            "subsections": []
        },
        "HOOKS": {
            "content": "How do I use hooks to prevent users from making certain changes?\nThe only safe place to make these changes is on the remote repository (i.e., the Git\nserver), usually in the pre-receive hook or in a continuous integration (CI) system.\nThese are the locations in which policy can be enforced effectively.\n\nIt’s common to try to use pre-commit hooks (or, for commit messages, commit-msg hooks) to\ncheck these things, which is great if you’re working as a solo developer and want the\ntooling to help you. However, using hooks on a developer machine is not effective as a\npolicy control because a user can bypass these hooks with --no-verify without being\nnoticed (among various other ways). Git assumes that the user is in control of their\nlocal repositories and doesn’t try to prevent this or tattle on the user.\n\nIn addition, some advanced users find pre-commit hooks to be an impediment to workflows\nthat use temporary commits to stage work in progress or that create fixup commits, so\nit’s better to push these kinds of checks to the server anyway.\n",
            "subsections": []
        },
        "CROSS-PLATFORM ISSUES": {
            "content": "I’m on Windows and my text files are detected as binary.\nGit works best when you store text files as UTF-8. Many programs on Windows support\nUTF-8, but some do not and only use the little-endian UTF-16 format, which Git detects as\nbinary. If you can’t use UTF-8 with your programs, you can specify a working tree\nencoding that indicates which encoding your files should be checked out with, while still\nstoring these files as UTF-8 in the repository. This allows tools like git-diff(1) to\nwork as expected, while still allowing your tools to work.\n\nTo do so, you can specify a gitattributes(5) pattern with the working-tree-encoding\nattribute. For example, the following pattern sets all C files to use UTF-16LE-BOM, which\nis a common encoding on Windows:\n\n*.c     working-tree-encoding=UTF-16LE-BOM\n\nYou will need to run git add --renormalize to have this take effect. Note that if you are\nmaking these changes on a project that is used across platforms, you’ll probably want to\nmake it in a per-user configuration file or in the one in $GITDIR/info/attributes, since\nmaking it in a .gitattributes file in the repository will apply to all users of the\nrepository.\n\nSee the following entry for information about normalizing line endings as well, and see\ngitattributes(5) for more information about attribute files.\n\nI’m on Windows and git diff shows my files as having a ^M at the end.\nBy default, Git expects files to be stored with Unix line endings. As such, the carriage\nreturn (^M) that is part of a Windows line ending is shown because it is considered to be\ntrailing whitespace. Git defaults to showing trailing whitespace only on new lines, not\nexisting ones.\n\nYou can store the files in the repository with Unix line endings and convert them\nautomatically to your platform’s line endings. To do that, set the configuration option\ncore.eol to native and see the following entry for information about how to configure\nfiles as text or binary.\n\nYou can also control this behavior with the core.whitespace setting if you don’t wish to\nremove the carriage returns from your line endings.\n\nWhy do I have a file that’s always modified?\nInternally, Git always stores file names as sequences of bytes and doesn’t perform any\nencoding or case folding. However, Windows and macOS by default both perform case folding\non file names. As a result, it’s possible to end up with multiple files or directories\nwhose names differ only in case. Git can handle this just fine, but the file system can\nstore only one of these files, so when Git reads the other file to see its contents, it\nlooks modified.\n\nIt’s best to remove one of the files such that you only have one file. You can do this\nwith commands like the following (assuming two files AFile.txt and afile.txt) on an\notherwise clean working tree:\n\n$ git rm --cached AFile.txt\n$ git commit -m 'Remove files conflicting in case'\n$ git checkout .\n\nThis avoids touching the disk, but removes the additional file. Your project may prefer\nto adopt a naming convention, such as all-lowercase names, to avoid this problem from\noccurring again; such a convention can be checked using a pre-receive hook or as part of\na continuous integration (CI) system.\n\nIt is also possible for perpetually modified files to occur on any platform if a smudge\nor clean filter is in use on your system but a file was previously committed without\nrunning the smudge or clean filter. To fix this, run the following on an otherwise clean\nworking tree:\n\n$ git add --renormalize .\n\n\nWhat’s the recommended way to store files in Git?\nWhile Git can store and handle any file of any type, there are some settings that work\nbetter than others. In general, we recommend that text files be stored in UTF-8 without a\nbyte-order mark (BOM) with LF (Unix-style) endings. We also recommend the use of UTF-8\n(again, without BOM) in commit messages. These are the settings that work best across\nplatforms and with tools such as git diff and git merge.\n\nAdditionally, if you have a choice between storage formats that are text based or\nnon-text based, we recommend storing files in the text format and, if necessary,\ntransforming them into the other format. For example, a text-based SQL dump with one\nrecord per line will work much better for diffing and merging than an actual database\nfile. Similarly, text-based formats such as Markdown and AsciiDoc will work better than\nbinary formats such as Microsoft Word and PDF.\n\nSimilarly, storing binary dependencies (e.g., shared libraries or JAR files) or build\nproducts in the repository is generally not recommended. Dependencies and build products\nare best stored on an artifact or package server with only references, URLs, and hashes\nstored in the repository.\n\nWe also recommend setting a gitattributes(5) file to explicitly mark which files are text\nand which are binary. If you want Git to guess, you can set the attribute text=auto. For\nexample, the following might be appropriate in some projects:\n\n# By default, guess.\n*       text=auto\n# Mark all C files as text.\n*.c     text\n# Mark all JPEG files as binary.\n*.jpg   binary\n\nThese settings help tools pick the right format for output such as patches and result in\nfiles being checked out in the appropriate line ending for the platform.\n",
            "subsections": []
        },
        "GIT": {
            "content": "Part of the git(1) suite\n\n\n\nGit 2.34.1                                   02/26/2026                                    GITFAQ(7)",
            "subsections": []
        }
    },
    "summary": "gitfaq - Frequently asked questions about using Git",
    "flags": [],
    "examples": [],
    "see_also": []
}