Closed borissmidt closed 3 years ago
The conservative safeguard of the script is to only remove branches that have been merged back into the main (e.g. master
) branch, so removing them doesn't lose any data.
The philosophy behind this script is that you won't need those release/*
branches any longer, once they landed in master, right? It's currently not possible to exclude branch name patterns. I won't hard-code any exceptions in the script (even for a reasonably standardized branch naming convention 😉), because everyone has their own project preferences and conventions, and soon enough we'll need a config file for this tool, which is an absolute no-go for me.
However… if you insist, I can think of the following workaround:
$ git cleanup -n | grep -v release/ | sh
Hope this helps!
It is standard practive in the git workflow to have release branches. These release branches are like a stack of releases where 1 connects to the next so if a fix is made in release 0.1 it will driple down to 0.2, 0.3 and eventually master.
I think a warning should be added to the cleanup tool and if possible a git setting (idk if you can) like set upstream
etc for setting default ignored branches.
I was lucky that we also have tags and that i could patch it up in several minutes otherwise it would have cost me hours to just fix it.
could atleast a flag -f be added so one is i just want to remove and accept each one individually and a -f is just run idk what you do. like rm -r
and rm -rf
.
I just discovered that the git cleanup removes the release branches as wel :-1: I think it would be best to have somekind of 'are you sure' part in this tool and an -f flag to just do it. like the linux
rm
command.It should also by default ignore any branch starting with release/XX . To make it more 'conservative'.