Common git questions and answers
List of most commonly asked questions on stack overflow about git.
by Mark Amery
Undo a commit and redo
$ git commit -m "Something terribly misguided" $ git reset HEAD~ << edit files as necessary >> $ git add ... $ git commit -c ORIG_HEAD
This is what you want to undo.
This leaves your working tree (the state of your files on disk) unchanged but undoes the commit and leaves the changes you committed unstaged (so they'll appear as "Changes not staged for commit" in
git status, so you'll need to add them again before committing). If you only want to add more changes to the previous commit, or change the commit message1, you could use git reset --soft HEAD~ instead, which is like
git reset HEAD~(where HEAD~ is the same as HEAD~1) but leaves your existing changes staged.
Make corrections to working tree files.
git add anything that you want to include in your new commit.
Commit the changes, reusing the old commit message.
resetcopied the old head to
.git/ORIG_HEAD; commit with -c ORIG_HEADwill open an editor, which initially contains the log message from the old commit and allows you to edit it. If you do not need to edit the message, you could use the -C option.
Beware however that if you have added any new changes to the index, using
commit --amend will add them to your previous commit.
If the code is already pushed to your server and you have permissions to overwrite history (rebase) then:
git push origin master --force
You can also look at this answer:
The above answer will show you git reflog which is used to find out what is the SHA-1 which you wish to revert to. Once you found the point to which you wish to undo to use the sequence of commands as explained above.
1 Note, however, that you don't need to reset to an earlier commit if you just made a mistake in your commit message. The easier option is to git reset (to upstage any changes you've made since) and then git commit --amend, which will open your default commit message editor pre-populated with the last commit message
$ git push --delete <remote_name> <branch_name> $ git branch -d <branch_name>
Note that in most cases the remote name is origin.
Delete Local Branch To delete the local branch use one of the following:
$ git branch -d branch_name $ git branch -D branch_name
-d option is an alias for
--delete, which only deletes the branch if it has already been fully merged in its upstream branch. You could also use
-D, which is an alias for
--delete --force, which deletes the branch "irrespective of its merged status." [Source: man git-branch]
Delete Remote Branch [Updated on 8-Sep-2017] As of Git v1.7.0, you can delete a remote branch using
$ git push <remote_name> --delete <branch_name>
which might be easier to remember than
$ git push <remote_name> :<branch_name>
which was added in Git v1.5.0 "to delete a remote branch or a tag."
Starting on Git v2.8.0 you can also use git push with the -d option as an alias for --delete.
Therefore, the version of Git you have installed will dictate whether you need to use the easier or harder syntax.
Delete Remote Branch [Original Answer from 5-Jan-2010] From Chapter 3 of Pro Git by Scott Chacon:
Deleting Remote Branches Suppose you’re done with a remote branch — say, you and your collaborators are finished with a feature and have merged it into your remote’s master branch (or whatever branch your stable code-line is in). You can delete a remote branch using the rather obtuse syntax
git push [remotename] :[branch]. If you want to delete your server-fix branch from the server, you run the following:
git push origin :serverfixTo email@example.com:schacon/simplegit.git - [deleted] serverfix Boom. No more branch on your server. You may want to dog-ear this page, because you’ll need that command, and you’ll likely forget the syntax. A way to remember this command is by recalling the git push [remotename] [localbranch]:[remotebranch] syntax that we went over a bit earlier. If you leave off the [localbranch] portion, then you’re basically saying, “Take nothing on my side and make it be [remotebranch].”
git push origin :bugfixand it worked beautifully. Scott Chacon was right—I will want to dog ear that page (or virtually dog ear by answering this on Stack Overflow).
Then you should execute this on other machines
git fetch --all --prune
to propagate changes.
by Greg Hewgill
In the simplest terms,
git pull does a
git fetch followed by a
You can do a
git fetch at any time to update your remote-tracking branches under
This operation never changes any of your own local branches under
refs/heads, and is safe to do without changing your working copy. I have even heard of people running
git fetch periodically in a cron job in the background (although I wouldn't recommend doing this).
git pull is what you would do to bring a local branch up-to-date with its remote version, while also updating your other remote-tracking branches.
Git documentation: git pull
by genehack You can undo git add before commit with
git reset <file>
which will remove it from the current index (the "about to be committed" list) without changing anything else.
You can use
without any file name to unstage all due changes. This can come in handy when there are too many files to be listed one by one in a reasonable amount of time.
In old versions of Git, the above commands are equivalent to
git reset HEAD <file> and
git reset HEAD respectively, and will fail if HEAD is undefined (because you haven't yet made any commits in your repo) or ambiguous (because you created a branch called
HEAD, which is a stupid thing that you shouldn't do). This was changed in Git 1.8.2, though, so in modern versions of Git you can use the commands above even prior to making your first commit:
git reset(without options or parameters) used to error out when you do not have any commits in your history, but it now gives you an empty index (to match non-existent commit you are not even on).
by siride If you want to rename a branch while pointed to any branch, do:
git branch -m <oldname> <newname>
If you want to rename the current branch, you can do:
git branch -m <newname>
A way to remember this, is -m is for "move" (or mv), which is how you rename files.
As per the Git Documentation git clean
Remove untracked files from the working tree
Step 1 is to show what will be deleted by using the -n option:
git clean -n
Clean Step - beware: this will delete files:
git clean -f
To remove directories, run
git clean -f -d or
git clean -fd
To remove ignored files, run
git clean -f -X or
git clean -fX
To remove ignored and non-ignored files, run
git clean -f -x or
git clean -fx
Note the case difference on the
X for the two latter commands.
clean.requireForce is set to "true" (the default) in your configuration, one needs to specify
-f otherwise nothing will actually happen.
Again see the git-clean docs for more information.
If the Git configuration variable clean.requireForce is not set to false, git clean will refuse to run unless given -f, -n or -i.
Don’t use the standard ignore rules read from .gitignore (per directory) and $GIT_DIR/info/exclude, but do still use the ignore rules given with -e options. This allows removing all untracked files, including build products. This can be used (possibly in conjunction with git reset) to create a pristine working directory to test a clean build.
Remove only files ignored by Git. This may be useful to rebuild everything from scratch, but keep manually created files.
Don’t actually remove anything, just show what would be done.
Remove untracked directories in addition to untracked files. If an untracked directory is managed by a different Git repository, it is not removed by default. Use -f option twice if you really want to remove such a directory.
For a given branch called test
git checkout test
git checkout test will NOT work in modern git if you have multiple remotes. In this case use
git checkout -b test <name of remote>/test
or the shorthand
git checkout -t <name of remote>/test
DISCLAIMER: I don't own rights to any of this answers and all of it are from stackover. I just listed them for easy reading.