On 03/22/2012 08:50 PM, Gottlob Frege wrote:
I have a question for the git (or hg) people. Maybe the concrete situation will shed some light on some of the issues (or maybe I'll just get some help and stop pulling what's left of my hair out).
Should I do everything on a messy "work" branch and just sort it out when I am ready to push? Should I keep the features in separate branches, but pull from branch to branch all the time? (I don't think I want to spend that much time with the RCS. I like forgetting about it most of the time.)
Am I just doing it wrong? (And did any of this make any sense?)
Tony
My opinion is you should work the way you want to work and the tool should enhance your work flow and may ultimately end up changing the way you work. Some experiences that initially sold me on using git (and likely other dvcs's but I haven't tried them) were: 0) git-svn It worked well enough with tutorials and such that I could whet my appetite. I did rm -rf my cloned tree quite a few times the first week... 1) the stash command. I'm working on my main tree (no branches yet because I always used separate working copies for my alternate methods in svn). Someone needs a quick fix. I stash all of my current changes onto a "patch stack" now my tree looks clean like I've just checked out. I fix the couple lines, commit, push (dcommit with git-svn), and pop the stash which merges my previous work with the quick fix in my working copy and I'm back to where I was before I was "interrupted." This setup is able to happen before I've completely lost my train of thought of the feature I was working on. Stash is also key for working with git-svn for being able to sync with the svn repo and having changes in the WC...After switching to pure git repos, I don't use stash nearly as much, but it was a great first impression. 2) git gui tool. It is simple enough to rapidly see what has changed, write your commit message, and commit. It's a very lightweight gui. Then I stumbled across cherry picking, you highlight the lines you want in or out of the commit, and you've now made a new patch. I know svn added this a while back, but I've never used it. Not sure why, probably because it wasn't there when I first started using svn and developed my svn habits... 3) Branches. Eventually I got brave and explored branches...The end result is I only have one tree for a project and a branch for every feature/variant I'm working on. I used to have a separate working copy directory for each svn. In the beginning, I was confused often by what branch am I in now? However, gitk is a great tool to graphically show the history of branches. git gui has great support for working with branches, and now I'm just in the habit of running 'git branch' much as I type 'ls' a lot. I think there are some shells that allow you to include the branch name in the command line prompt, but I haven't needed that yet. Again, svn has had 'svn switch' for a while but for some reason, it never became part of my routine working style. 4) The concept of "staging." It caused no end of confusion initially. In svn, the WC is the stage. In git (presumably other DVCS), the stage is decoupled from the WC. It's quite valuable to use git gui to see what is staged for committing. I'm not exactly sure why, but it's comforting to really know what's going in your commit before happens. I think the main difference from a user perspective is that git allows me to be more sloppy during development, i.e. modify many files not necessarily related to a feature that I want to check in, but be very precise when I do check in (and to fix my mistakes with amend last commit) if I catch them quickly enough, i.e. forgetting to 'add' a file. 5) As shared in the other thread, each generation of vcs has had a profound impact on my development style. Starting with making backup directories, to scripts that make backup tar balls, to rcs, to cvs, to svn, and now to git. The number of "commits" I make have increased in frequency with each tool. I guess this gives me more courage to refactor more aggressively or explore different ideas more readily because I know I can roll back to a previous working state and that I haven't spent much time investing in the attempt and I can delete it, clean it up, and make it pretty before I have to share the patch with my peers. 6) Not very objective, but my experience with git vs svn is that git is lightweight (fast) enough to be part of my development while I develop vs svn which seems more heavyweight and part of the process that I do at the end of development rather than something I use during.