I'm new to the Git environment, and I'm using BitBucket with SourceTree on Mac. All I want to do now is to discard the changes since last commit. How should I do this? I haven't found anything like "discard changes", and directly pulling from the last commit doesn't seem to work. Solutions done with either the GUI or command line will be good.
On SourceTree for Mac, right click the files you want to discard (in the Files in the working tree list), and choose Reset.
On SourceTree for Windows, right click the files you want to discard (in the Working Copy Changes list), and choose Discard.
On git, you'd simply do:
git reset --hard to discard changes made to versioned files;
git clean -xdf to erase new (untracked) files, including ignored ones (the x option). d is to also remove untracked directories and f to force.
I like to use
git stash
This stores all uncommitted changes in the stash. If you want to discard these changes later just git stash drop (or git stash pop to restore them).
Though this is technically not the "proper" way to discard changes (as other answers and comments have pointed out).
SourceTree: On the top bar click on icon 'Stash', type its name and create. Then in left vertical menu you can "show" all Stash and delete in right-click menu. There is probably no other way in ST to discard all files at once.
Follow steps to discard multiple uncommited changes in Sourcetree.
New version of Sourcetree does not have -Reset Button- as mentioned previous answer. Thus, please follow these 5 steps for solution.
Right click "File status" and click "Reset...".
Select files. If you want, you can select all of them like the below image.
Click "Reset All".
Again click "Reset All".
Click "Reset".
Welldone..! No more 302 files to discard.
On the unstaged file, click on the three dots on the right side. Once you click it, a popover menu will appear where you can then Discard file.
Ok I just noticed that my question was already answered in the question title.
To unstage files use
git reset HEAD /file/name
And to undo the changes to a file
git checkout -- /file/name
If you have a batch of files inside a folder you can undo the whole folder
git checkout -- /folder/name
Note that all these commands are already displayed when you git status
Here I created a dummy repo and listed all 3 possibilities
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: test
#
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: test2
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# test3
From sourcetree gui click on working directoy, right-click the file(s) that you want to discard, then click on Discard
Ok so in Windows sourcetree that is simple, on macOS I looked as well for a while..
Click Command + Shift + R while in source tree a hidden popup will be shown that will let you discard individual files OR ALL! Why is this hidden? We will never know.. but it works!
Do as follow,
Click on commit
Select all by pressing CMD+A that you want to delete or discard
Right click on the selected uncommitted files that you want to delete
Select Remove from the drop-down list
It's Ctrl + Shift + r
For me, there was only one option to discard all.
Related
In Git, I was trying to do a squash commit by merging in another branch and then resetting HEAD to the previous place via:
git reset origin/master
But I need to step out of this. How can I move HEAD back to the previous location?
I have the SHA-1 fragment (23b6772) of the commit that I need to move it to. How can I get back to this commit?
Before answering, let's add some background, explaining what this HEAD is.
First of all what is HEAD?
HEAD is simply a reference to the current commit (latest) on the current branch.
There can only be a single HEAD at any given time (excluding git worktree).
The content of HEAD is stored inside .git/HEAD and it contains the 40 bytes SHA-1 of the current commit.
detached HEAD
If you are not on the latest commit - meaning that HEAD is pointing to a prior commit in history it's called detached HEAD.
On the command line, it will look like this - SHA-1 instead of the branch name since the HEAD is not pointing to the tip of the current branch:
A few options on how to recover from a detached HEAD:
git checkout
git checkout <commit_id>
git checkout -b <new branch> <commit_id>
git checkout HEAD~X // x is the number of commits to go back
This will checkout the new branch pointing to the desired commit.
This command will checkout to a given commit.
At this point, you can create a branch and start to work from this point on.
# Checkout a given commit.
# Doing so will result in a `detached HEAD` which mean that the `HEAD`
# is not pointing to the latest so you will need to checkout branch
# in order to be able to update the code.
git checkout <commit-id>
# Create a new branch forked to the given commit
git checkout -b <branch name>
git reflog
You can always use the reflog as well.
git reflog will display any change which updated the HEAD and checking out the desired reflog entry will set the HEAD back to this commit.
Every time the HEAD is modified there will be a new entry in the reflog
git reflog
git checkout HEAD#{...}
This will get you back to your desired commit
git reset --hard <commit_id>
"Move" your HEAD back to the desired commit.
# This will destroy any local modifications.
# Don't do it if you have uncommitted work you want to keep.
git reset --hard 0d1d7fc32
# Alternatively, if there's work to keep:
git stash
git reset --hard 0d1d7fc32
git stash pop
# This saves the modifications, then reapplies that patch after resetting.
# You could get merge conflicts if you've modified things which were
# changed since the commit you reset to.
Note: (Since Git 2.7) you can also use the git rebase --no-autostash as well.
git revert <sha-1>
"Undo" the given commit or commit range.
The revert command will "undo" any changes made in the given commit.
A new commit with the undo patch will be committed while the original commit will remain in history as well.
# Add a new commit with the undo of the original one.
# The <sha-1> can be any commit(s) or commit range
git revert <sha-1>
This schema illustrates which command does what.
As you can see there, reset && checkout modify the HEAD.
First reset locally:
git reset 23b6772
To see if you're on the right position, verify with:
git status
You will see something like:
On branch master Your branch is behind 'origin/master' by 17 commits,
and can be fast-forwarded.
Then rewrite history on your remote tracking branch to reflect the change:
git push --force-with-lease // a useful command #oktober mentions in comments
Using --force-with-lease instead of --force will raise an error if others have meanwhile committed to the remote branch, in which case you should fetch first. More info in this article.
Quickest possible solution (just 1 step)
Use git checkout -
You will see Switched to branch <branch_name>. Confirm it's the branch you want.
Brief explanation: this command will move HEAD back to its last position. See note on outcomes at the end of this answer.
Mnemonic: this approach is a lot like using cd - to return to your previously visited directory. Syntax and the applicable cases are a pretty good match (e.g. it's useful when you actually want HEAD to return to where it was).
More methodical solution (2-steps, but memorable)
The quick approach solves the OP's question. But what if your situation is slightly different: say you have restarted Bash then found yourself with HEAD detached. In that case, here are 2 simple, easily remembered steps.
1. Pick the branch you need
Use git branch -v
You see a list of existing local branches. Grab the branch name that suits your needs.
2. Move HEAD to it
Use git checkout <branch_name>
You will see Switched to branch <branch_name>. Success!
Outcomes
With either method, you can now continue adding and committing your work as before: your next changes will be tracked on <branch_name>.
Note that both git checkout - and git checkout <branch_name> will give additional instructions if you have committed changes while HEAD was detached.
The question can be read as:
I was in detached-state with HEAD at 23b6772 and typed git reset origin/master (because I wanted to squash). Now I've changed my mind, how do I go back to HEAD being at 23b6772?
The straightforward answer being: git reset 23b6772
But I hit this question because I got sick of typing (copy & pasting) commit hashes or its abbreviation each time I wanted to reference the previous HEAD and was Googling to see if there were any kind of shorthand.
It turns out there is!
git reset - (or in my case git cherry-pick -)
Which incidentally was the same as cd - to return to the previous current directory in *nix! So hurrah, I learned two things with one stone.
When you run the command git checkout commit_id then HEAD detached from 13ca5593d(say commit-id) and branch will be on longer available.
Move back to previous location run the command step wise -
git pull origin branch_name (say master)
git checkout branch_name
git pull origin branch_name
You will be back to the previous location with an updated commit from the remote repository.
Today, I mistakenly checked out on a commit and started working on it, making some commits on a detach HEAD state. Then I pushed to the remote branch using the following command:
git push origin HEAD: <My-remote-branch>
Then
git checkout <My-remote-branch>
Then
git pull
I finally got my all changes in my branch that I made in detach HEAD.
This may not be a technical solution, but it works. (if anyone of your teammate has the same branch in local)
Let's assume your branch name as branch-xxx.
Steps to Solve:
Don't do update or pull - nothing
Just create a new branch (branch-yyy) from branch-xxx on his machine
That's all, all your existing changes will be in this new branch (branch-yyy). You can continue your work with this branch.
Note: Again, this is not a technical solution, but it will help for sure.
Move last non-pushed commits to a new branch
If your problem is that you started committing on the WRONG_BRANCH, and want to move those last non-pushed commits to the RIGHT_BRANCH, the easiest thing to do is
git checkout WRONG_BRANCH
git branch RIGHT_BRANCH
git reset —-hard LAST_PUSHED_COMMIT
git checkout RIGHT_BRANCH
At this point, if you run git log HEAD you will see that all your commits are there, in the RIGHT_BRACH.
Data
WRONG_BRANCH is where your committed changes (yet to push) are now
RIGHT_BRANCH is where your committed changes (yet to push) will be
LAST_PUSHED_COMMIT is where you want to restore the WRONG_BRANCH to
Say you do git status and you get back a list of files which you want to check one by one and then commit them one by one.
Or you do a git diff on a directory and want to go and commit directly after your inspection. How to do that with a simple trick?
If you are in a GUI environment. You can launch "git gui" from the console..
This would launch a window, where the left pane would contain the list of changed files. Selecting any of them, shows you the diff.
You can add files by clicking on the icon to the left of the file name and later commit it from the same window.
Hope it helps.
Note: diff + commit would not work because you have not added anything to the index.
As commented, git add -i or git add -p (--patch) will give you a diff view, with the possibility to add or skip each diff hunk.
Then you can commit the modified index.
UPDATE 2020:
After fiddling around I decided to install and use ydiff.
Doing ydiff -s shows a diff side by side in the terminal.
No brainer check it out here and don't mind my old answer:
https://github.com/ymattw/ydiff
[ OLD
]
Git diff before your commit?
Simple solution thinking outside of the box:
Stick this in your .bashrc or .zshrc:
gdiffy() { git diff $1 && git add $1 && git commit $1; }
First it will pop open up a diff, when you close it, it will allow you enter a commit message.
usage example:
gdiffy config/database.yml
or
gdiffy .
I use TortoiseGit 1.8.3.
I changed one of the files: Makefile, but I want to not offer commit it to me every once in a Git Commit.
I added it to the "delete and add to ignore list", but it does not help.
How do I make to some of the files that I have changed is not offered in the commit?
I want, that Makefile was in remote repository as read-only, that I could edit it locally, and then TortoiseGit does not offer to me to commit it.
That I wanted for Git-bash: https://www.kernel.org/pub/software/scm/git/docs/git-update-index.html
Answer for TortoiseGit 1.8.15, Git 2.6.1. There is no need to revert to the command line, all functions are directly available in TortoiseGit. I've tried to summarize the various ways how this function is accessible.
I assume that the reader knows what "assume unchanged" means. Here is easy documentation about this feature. Or the original documentation about --assume-unchanged or git ls-files.
Flag a file as "assume unchanged"
There are three possibilities in TortoiseGit: in the Commit dialog, the Working Tree dialog (Check for Modifications) or in the Log Messages dialog (only when Working dir changes entry is selected). From one of these dialogs do the following:
right-click the file and select the entry Assume Unchanged
From any file list in Windows Explorer do the following:
right-click the file and select properties
go to the Git tab
tick the entry Assume valid/unchanged
Remove the "assume unchanged" flag from a file (undo the above):
TortoiseGit allows to remove the flag only from the Working Tree dialog (check for Modifications).
in the lower left corner of the dialog: make sure to tick the option Show ignore local changeds flagged files
all files with assumed valid or skip worktree flag will be shown below the normal changed files
right-click on the file and select Unflag as skip-worktree or assume-unchanged
From any file list in Windows Explorer do the following:
right-click the file and select properties
go to the Git tab
untick the entry Assume valid/unchanged
If I'm interpreting the question correctly, Alex wants to know how to undo an --assumed-unchanged action done using Tortoise Git.
You don't need to use command line Git to fix this:
Navigate to the file(s) you did this action on in windows explorer,
Right-click and choose Properties,
Select the Git tab, there you should see a checked box next to "Assume valid/unchanged".
Uncheck it and it won't be ignored by commits moving forward.
The approved answer is good but in case you're hunting for the dialogues and options here you have a short help:
If it doesn't help, then you need to go to a command-line interface, and check:
the content of the .gitignore file that you should find at the root directory of your repo (as mentioned in "TortoiseGit: hide/remove files never to be versioned")
the result of git rm --cached Makefile.
the result of git status.
I want, that Makefile was in remote repository in read-only, that I could edit it localy, and then TortoiseGIT does not offer to me to commit it.
This is different:
You need:
git update-index --really-refresh --no-assume-unchanged Makefile
That will make any local modification to Makefile "invisible" to git, while keeping Makefile under source control.
If you want your local modifs to resist a git reset, do;
git update-index --skip-worktree Makefile
I have created a project called zz and it has a single file called ruby.rb in it. I am using git. I have already added ruby.rb to the staging area. Now I have modified the ruby.rb file and using git status below is the output.
nikhil#pc:/home/rapps/zz$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: ruby.rb
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# ruby.rb~
no changes added to commit (use "git add" and/or "git commit -a")
Now I see another file ruby.rb~ even though, I did not created it. Is git creating this file. I have seen tutorials on Internet and I think I have found this on my system only.
I'm on Ubuntu 10.10 using gedit with gmate plug-gins.
That's a temporary file created by some text editors. You may wish to create a .gitignore file to automatically ignore such files to prevent them from accidentally being added to your repository. You would put
*~
in your .gitignore file to exclude all files ending with a tilde.
Git does not create these files on my system, but I know gedit has a back-up system. If you disable the backup in gedit's preferences, the files should not be created again.
You can put this into the .gitignore file so git won't commit them:
*~
No, Git does not create files like ruby.rb~ This is a common method text editor applications do to save backups of the currently edited file.
No, git is not adding this file. It is likely being used as a file buffer or backup by your text editor. If you close your text editor, does the file disappear?
Git won't ever add a file or change the file system of your repository except in the .git directory, which Git knows to treat different.
I am developing in the 'master' branch and want to copy some files from 'feature-1'. How can I do that with TortoiseGit?
(I am not interested in command-line solutions.)
tortoisegit -> show log..
in the upper part of window, select the commit (click all branches if necessary) you want the file from
copy file(s) from revision to where?
into workdir: select the file(s) you want, right-click -> revert to this revision
single file anywhere: select single file, right-click -> save revision to...
many files (that are not same as in work dir) anywhere, with directories: right-click the commit, select Compare with working copy, select file(s), right-click, export selection to..."
everything in a single commit (as zip): right-click commit, select export this version..
..or just use the command line, it's easier.
I would like to add something. In my case I was looking for specific files located in different branches, so I had to add a search text in (1) and in (2) I selected Branch. Finally, for each file I selected Revert to this revision .