I would do that:
git stash (to save your untracked files of the branch your working on)
git checkout develop
git log (here get the hash of your HEAD)
git reset --hard <HASH/TAG> (to the point you want to go back in the
history, can be nothing if your current version is stable)
git checkout <REMOTE_BRANCH_TO_TEST>
Test the branch, once finished:
git reset --hard <HEAD> (the hash you previously saved).
git checkout <BRANCH> (the branch you're working on)
git stash apply (to get back your untracked files)
-Fred
-----Message d'origine-----
From: Alex Harui
Sent: Saturday, March 23, 2013 2:58 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
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" <labri...@digitalprimates.net>
wrote:
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
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
