On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <gosm...@adobe.com> wrote: > I plan to do my Falcon development work on the 'develop' branch. The full > nvie model is complete overkill for what I am doing and I don't need umpteen > feature branches. Has everyone forgotten about KISS? > > - Gordon >
I understand where all the confusion comes from and taken as a whole, it does seem like overkill. I think it's less so in practice but by way of example, here is a minimal version of what I do on a daily basis for my own projects. Maybe some of this helps, maybe not. I am not trying to assert my workflow for any of you. You are doing work on this and I am not. Just thought it might help presented this way and help you see where I see the value. Let's say I am going to work on refactoring SomePiece. I make a quick branch called SomePieceRefactor. First, what does this mean. In git this really just means that I am going to record a pointer to where the code was when I started so that I can easily go back. It's just a pointer to what code looked like at a point in time, not a copy. Second, why bother? A couple of reasons. I might work on SomePiece but before I have the chance to finish I need to go patch a bug elsewhere, I can easily keep my changes and go back to what the repo looked like before. Or perhaps someone else on my team commits a potential fix for something and wants my opinion. It may not work (or simply might not be fair) to integrate that with my half-baked code. So, instead, I can jump back to the last point where the repo was stable. Make a quick branch called TestJimsChanges, pull in his changes and review. If they look good, I can then leave them be, or (if I really need them) switch back to my SomePieceRefactor and integrate his code. The point of the branches are really just pointers or bookmarks that I can use the manage my own workflow. They really aren't (at this point) for anyone else. When I am satisfied with SomePieceRefactor, I tend to leave that branch hanging around. Why? Well, for me, it's useful because later when someone discovers a bug, I can very quickly go back and test against my unmodified code. Was the bug there from the beginning or was it caused by something after this point or something someone else did? I quickly reduce the amount of debugging I do by having these points in history to look at. When all is said and done, I push my changes to develop. So, personally, I am not making a million branches out in the project, the branches are for me, they are for my workflow and they are tools I use. So what does this extra branch/workflow cost me. Well, in my experience so far it's actually saved me time, not cost me any. Making a branch is a quarter of a second of my time and the fact that I can task switch so quickly, review others code, test combinations (their code with the original branch, their code with my latest) before I need make any final commitments to pushing these live is hugely helpful to me. So, everyone's mileage may vary and again you need to do what you feel is best, but I wanted to provide a concrete though on the whole branching thing and perhaps peel back some of the complexity of the situation. Hope that helps a little, Mike
