Well if he was modifying files in a feature branch then switched to an entirely different branch to do that testing... would he even have to worry about stashing or such?
On Sat, Mar 23, 2013 at 10:17 AM, Frédéric THOMAS <webdoubl...@hotmail.com>wrote: > 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 > >
