git-clean - Remove untracked files from the working tree
Synopsis
git clean [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [--] <path>…
Description
Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.
Normally, only files unknown to Git are removed, but if the -x
option is specified, ignored files are also removed. This can, for example, be useful to remove all build products.
If any optional <path>...
arguments are given, only those paths are affected.
Step 1 is to show what will be deleted by using the -n
option:
# Print out the list of files and directories which will be removed (dry run)
git clean -n -d
Clean Step - beware: this will delete files:
# Delete the files from the repository
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.
If 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.
Options
-f
, --force
If the Git configuration variable clean.requireForce is not set to
false, git clean will refuse to run unless given -f
, -n
or -i
.
-x
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.
-X
Remove only files ignored by Git. This may be useful to rebuild
everything from scratch, but keep manually created files.
-n
, --dry-run
Don’t actually remove anything, just show what would be done.
-d
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.
Try: git mergetool
It opens a GUI that steps you through each conflict, and you get to choose how to merge. Sometimes it requires a bit of hand editing afterwards, but usually it's enough by itself. It is much better than doing the whole thing by hand certainly.
As per Josh Glover's comment:
The command
doesn't necessarily open a GUI unless you install one. Running git mergetool
for me resulted in vimdiff
being used. You can install
one of the following tools to use it instead: meld
, opendiff
,
kdiff3
, tkdiff
, xxdiff
, tortoisemerge
, gvimdiff
, diffuse
,
ecmerge
, p4merge
, araxis
, vimdiff
, emerge
.
Below is the sample procedure to use vimdiff
for resolve merge conflicts. Based on this link
Step 1: Run following commands in your terminal
git config merge.tool vimdiff
git config merge.conflictstyle diff3
git config mergetool.prompt false
This will set vimdiff as the default merge tool.
Step 2: Run following command in terminal
git mergetool
Step 3: You will see a vimdiff display in following format
╔═══════╦══════╦════════╗
║ ║ ║ ║
║ LOCAL ║ BASE ║ REMOTE ║
║ ║ ║ ║
╠═══════╩══════╩════════╣
║ ║
║ MERGED ║
║ ║
╚═══════════════════════╝
These 4 views are
LOCAL – this is file from the current branch
BASE – common ancestor, how file looked before both changes
REMOTE – file you are merging into your branch
MERGED – merge result, this is what gets saved in the repo
You can navigate among these views using ctrl+w. You can directly reach MERGED view using ctrl+w followed by j.
More information about vimdiff navigation is here and here.
Step 4. You could edit the MERGED view the following way
If you want to get changes from REMOTE
:diffg RE
If you want to get changes from BASE
:diffg BA
If you want to get changes from LOCAL
:diffg LO
Step 5. Save, Exit, Commit and Clean up
:wqa
save and exit from vi
git commit -m "message"
git clean
Remove extra files (e.g. *.orig) created by diff tool.
Best Answer
You should use
git rebase --onto
here, and specify a range.(see
git rebase
man page:).
Of course, this would move your
bug10
branch on top of thelegacy
branch, which is not what you want/need.So, one workaround would be to do that rebase in a cloned repo, then merge that 'enhanced'
legacy
branch (the one in the clone repo, with thebug10
modifications on top of it) to the local and currentlegacy
branch (the one you want to modify, while leavingbug10
alone).Now:
legacy
branch, so the other answers (patch) are valid (and simpler).bug10
commits), before pushing only that branchlegacy
to your original repo (you would not pushbug10
, since its history would have been entirely rewritten!)I just wanted to see if it works, so... Let's test that approach.
(Git1.6.5.1, on a old XP SP2, with a Powershell 1.0 session because of the
Start-Transcript
command)I like how I do not have anymore to make the git repo directory first, then type in it
git init
! Since 1.6.5:This is GREAT!
Let's create 3 files, for 3 different purposes.
(For the sake of example, I will keep the file modifications separate per branch: no conflict during merge or rebase here.)
At this point, a
git log --graph --oneline --branches
returns:Let's build a
legacy
branchWe return to master, make another commit, which we will tag "2.0" (a release which will need some bug-fixing!)
We have:
Now we do a
bug10
bug-fixing branch:Let's add a final commit on the main branch
Final state of our main repo:
At this stage, I will not make any further manipulation in mainRepo. I will only clone it to make some tests. If those fails, I can always get back to this repo and clone it again.
The first clone is actually mandatory, in order to perform our
git rebase --onto
We need two of the mainRepo branches in our cloned repo:
Let's rebase only bug10 (that is all commits after
2.0
tag up toHEAD
ofbug10
branch):At this point
bug10
has been replayed on top oflegacy
without all the other intermediate commits.We can now fast-forward
HEAD
oflegacy
to the top of the replayedbug10
branch.The content follow what we need:
main
branch is there only up to1.0
tag (root forlegacy
branch), and not any further.bug10
fixes are here:That's it.
The idea is to to pull that 'enhanced'
legacy
branch in your original repo, which will still have itsbug10
unchanged (i.e. still starting from the2.0
tag, and not replayed anywhere like we did on therebaseRepo
.In this cloned repo, I track the
origin/legacy
branch, in order to merge on it thelegacy
branch of another remote source: therebaseRepo
.In this original repo (I only cloned it to not mess with the state of the mainRepo, in case I had some other experiments to do), I will declare
rebaseRepo
as a remote, and fetch its branches.We can now update
legacy
without touching tobug10
:You can repeat the process as many time as you want, whenever new
bug10
commits need to be replayed on top of an oldlegacy
branch, without including all the intermediate commits.