Is it different if you have stuff already staged and/or committed?
On 3/23/13 7:52 AM, "Frédéric THOMAS" <[email protected]> wrote: > Hi, > > I'm not sure I understand what you ask but your untracked files are here for > every branches, so it's better to stashed them, your stage area will be > stashed as well. > btw, to include untracked files it's "git stash -u", sorry :P > > -Fred > > -----Message d'origine----- > From: Mark Kessler > Sent: Saturday, March 23, 2013 3:32 PM > To: [email protected] > Subject: Re: [OT] Log history > > 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 > <[email protected]>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: [email protected] >> 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" <[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 >> >> > -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
