OK, nice story. But for me, I have no idea how you "pull in his changes and review". Or "go back and test against unmodified code". And are you stashing or committing your changes first? What git commands and flags do you use?
And the main debate is: if you have a simple change to the README, are you creating a branch for that? On 3/23/13 2:05 AM, "Michael A. Labriola" <[email protected]> wrote: > > On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <[email protected]> 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 > > > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
