That sounds like all the good way to work with branches to me.
-Fred
-----Message d'origine-----
From: Michael A. Labriola
Sent: Saturday, March 23, 2013 10:05 AM
To: dev@flex.apache.org
Subject: RE: [OT] Log history
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
