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
