2012/10/11 Arnaud Héritier <aherit...@gmail.com> > Now let's say that someone wants to solve a problem on a maintenance branch > (thus not master) > With git it will checkout this branch to work on the fix, but if in // he > wants to add an IT it will add it on this branch (not on master where we > should have all ITs ?) > How many chance that one day we forgot to merge back ITs from all branches > in master ? >
If you make any kind of change on a branch (bugfix/feature/whatever) I would expect to have test updates being done on that branch too, so the branch represents a complete "diff" of the change; both feature and tests. When the fix/feature is merged back into master the tests come along, if the feature is never merged to master, the tests stay in their branch - just like they should. This is a healthy mode of operation; if you look at the branches in my surefire github repo (https://github.com/krosenvold/maven-surefire) I have like 15 different branches. Some of them are specific JIRAs and may contain testcases and partial fixes. Now I will start pushing these to the ASF git repo instead, since they represent work on an issue that is not fully fixed; maybe just a testcase or a test project. I think it's important we acknowledge the existence/intention of such branches on the corresponding JIRA when we make such feature branches in the official repo. If I just push it to my personal github repo it can be as messy as I prefer, but when I push it to ASF I'd prefer it to have reasonably well-defined responsibility (like test-case, suggested fix or similar) and some value to others. If it's just my personal doodles I'll keep them in my personal github. As for branches that never get merged back; well that's life and usually there's a story behind that and we tell it in jira. Kristian
