Hi metellius, I don't know what the "correct" way of doing things are, if there is even such a thing. Git supports a lot of different ways of achieving the same goal. In my experience all the different ways you are describing are good ways of handling the work flow. We are a small team who have experimented with different ways of using git and found that git stash and many small commits are good things. Also we use the no fast forward switch when merging and pulling stuff into our main branch. In this way it becomes very easy to "undo" a merge and it also becomes easy to get an overview of the history. I'm not saying that this is the only, best or correct way to use git, just that it's what we've discovered works best for us after some experimentation.
On Tue, Nov 25, 2008 at 2:43 AM, metellius <[EMAIL PROTECTED]> wrote: > > Hello, here's the situation I am facing these days. Originally, I saw > the branches as a way to contain small changes that I might/might not > choose to actually merge with the code later. So I started out with > lots of small branches of things that I worked on similarly. And since > it is not possible to switch branches without having a clean workdir > (eg, commiting), I ended up commiting really small, sometimes even non- > working commits just because I wanted to switch to another branch and > work on that one. I thought this was OK, until I discovered that git > actually just forwarded these commits when I merged the branch, and > the final git log was really messed up. > > Now, I've head that it's possible to disable this forward-commits-from- > branch way of merging, but since it's default, I'm assuming it's > supposed to be part of the "correct" way of using git. So what do I do > then, when I want to quickly switch to another branch without being > finished with what I'm working on? Which is the git correct way of > doing it? Should I: > > 1. Never think such a thing, and just code until I have a complete > commit > 2. Use git-stash (and have to keep my own system of which stash > belongs where) > 3. Use commit with a temporary commit message, and then use the git > comit --amend method afterwards (forces me to be really careful about > what to push) > 4. Force git to not forward the commits, but instead merge them into a > single commit when I merge a branch (strays from the default git > setting, so feels weird) > > > -- Cheers, - Jacob Atzen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Gitorious" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/gitorious?hl=en -~----------~----~----~----~------~----~------~--~---
