They are written for Linux, but should work on OS X and even on Windows if you use Git Bash. Hereby an overview per scenario in increasing order of complexity.Īll of these methods assume that you are familiar with console commands. Depending on where the file is, you can use several methods. Simply git rm passwords.txt won't do it, as the file will still be there in all previous commits. Do you want to be the person who committed AWS keys to a public GitHub repository, only to find out 24 hours later that ~USD2000 has been spent mining bitcoins? Several methods The goal is to completely wipe a file out of existence in a Git repository, to cover all tracks of your horrible mistake.
#Git clean repository password#
In the previous example, we applied filter-branch to the whole branch.Have you already committed an SSH private key, a password file or a config file with sensitive data to your repository before? In case you did not, I would recommend to first try this out before you continue reading this blogpost.įor the rest of us: DON'T PANIC! Take a deep breath, get up from your desk, walk around for a few minutes. But if there are many patterns, of if the logic to remove files is more complex, it doesn’t really work out… In this case, you can just write a (bash) script that contains the necessary commands, and use this script as the command passed to git filter-branch -index-filter. In the example above, there were only 3 file patterns to remove, so the command was short enough to be written inline. If the branch has a long history, this command can take a while to run, so be patient… Once it’s done, you should have a branch with the same commits as the original branch, but without the unwanted files. By default, the command only applies to the current branch. The -cached parameter means we’re working on the index rather than on the working tree -ignore-unmatch tells Git to ignore patterns that don’t match any file. Git filter-branch -index-filter 'git rm -cached -ignore-unmatch **/bin/** **/obj/** packages/**' The filter-branch command with this kind of filter can be used as follows: In our current scenario, -index-filter is perfectly adequate, since we only need to filter files based on their path. -index-filter : a filter that applies to the index (doesn’t require checking out each commit, hence faster).-tree-filter : a filter that applies to the working tree (causes each commit to be checked out, so it can take a while on a large repo).-msg-filter : a filter that can rewrite commit messages.There are several kinds of filter, for instance:
This command works by taking each commit in the branch, applying a filter to it, and recommiting it with the changes caused by the filter.
#Git clean repository pro#
It’s described in the Pro Git book Pro Git as the “nuclear option”, because it’s very powerful and possibly destructive, so it should be used with great caution.
The Git command that will let us remove unwanted files is named filter-branch. Which gives us the following patterns to remove:Ĭleanup the branch: the git filter-branch command NET project, it’s usually the contents of the bin and obj directories (wherever they’re located) and the packages directory (usually at the root of the solution). So, assuming the branch we want to cleanup is master, let’s create a master2 working branch:īefore we start to cleanup, we need to identify what needs to be cleaned up. The easiest way to avoid causing damage to the original branch is, of course, to work on a separate branch. Since we’re going to make pretty drastic and possibly risky changes on the repo, we’d better be cautious. But don’t do this on a branch your colleagues are currently working on, unless you want them to hate you 😉. In my case, it didn’t matter, because I didn’t need to publish the rewritten branch (I just wanted to examine it locally). If someone else bases works on the existing branch and the branch has its history rewritten, it will become much harder to integrate their commits into the rewritten branch. The operation we need to perform here involves rewriting the history of the branch, so a warning is in order: never rewrite the history of a branch that is published and shared with other people. Let’s see step by step how this can be achieved. This made the history hard to follow, because each commit had hundreds of modified files.įortunately, it’s rather easy with Git to cleanup a branch, by recreating the same commits without the files that shouldn’t have been there in the first place. gitignore file, so a lot of useless files (bin/obj/packages directories…) had been commited. Unfortunately, the repo had been created without a. I recently had to work with a Git repository whose modifications needed to be ported to another repo.
0 kommentar(er)
