Re: Workflow question

[Russ Brown <pickscrape@gmail.com>]

Jeff King wrote:
> On Tue, Sep 25, 2007 at 03:56:56PM -0500, Russ Brown wrote:
> 
>> I keep reading things similar to this and bit by bit I'm starting to get
>> it. :) I suppose this is one case in which it's definitely a
>> disadvantage to have a good understanding of svn before coming to git...
>>
>> <yoda>You must unlearn what you have learned</yoda>
> 
> I prefer to think of it like a war movie, where I keep having
> nightmarish flashbacks to CVS.
> 
> But yes, from the outside git _looks_ a lot like other SCMs you may have
> used, and so it's tempting to keep their mental models. But that can
> easily end up being confusing, as you have found. Personally, I think it
> pays to learn a little about what's going on under the hood, and then
> all of the commands Just Make Sense.
> 
> There are several explanations floating around; this is a pretty concise
> one:
> 
>   http://eagain.net/articles/git-for-computer-scientists/
> 

Yes, this is very helpful indeed: thank you for that. /me bookmarks. I
hadn't actually realised that rebase creates new commits and replaces
your old ones: I'd thought they just got 'moved' (dunno how I thought it
worked though!)

>> If you delete a branch that has commits on it that aren't referenced by
>> any other branches, will those commits be removed by something like git
>> pack or git gc?
> 
> The 'git-prune' command will do this, though it is not run as part of
> git-gc unless you specify --prune.
> 

Another thing makes sense now (helped by the link above also).

>> I suppose what has me the most confused is how a developer works with a
>> remote branch: I've come to understand that a developer should never
>> check out and work on a remote branch, and always create a local one and
>> work on that. If he does that using the above hierarchy, there then
>> becomes main->projectX->featureY->jeff_local_branch_of_featureY. Or is
>> is possible for a developer to work directory on a remote branch?
> 
> As Junio noted, you can't, because they're remote. What you have in your
> local repository is a remote _tracking branch_, which is a local ref
> that tracks your idea of what the remote's branches are. And git will
> feel free to overwrite the contents of that tracking branch whenever you
> do a fetch or pull. So if you make commits on it, they are subject to
> being overwritten (and we note this property of the refs by putting them
> in the refs/remotes hierarchy, rather than refs/heads).
> 
> So in the case of our developer Jeff, his local repository will have a
> "projectX/featureY" branch that he works on. And he will also have a
> remote tracking branch "origin/projectX/featureY" which indicates where
> his local repo thinks the remote repo points. And the remote repo will
> have a "projectX/featureY" branch, of course.
> 

I'm just wondering at this point why git lets you checkout remote
tracking branches if it's something you really shouldn't do. Unless it's
something you want to be able to do in edge cases to fix screwups maybe?

>> Ah,I see... The light is beginning to come on somewhat here, though it's
>> dimmed somewhat by the remote/local branch confusion I mention above,
>> which tends to imply that rebase is only really useful in local branches
>> since it is always the outer-most branch (assuming that my understanding
>> on that is correct, which it may well not be).
> 
> Yes, although the important distinction is not so much "this is a local
> branch" but rather "this is a _published_ branch" which implies that
> other people are looking at (and possibly basing work on) it.
> 
>> I actually quite like the idea of the freezing before re-basing in the
>> sub-branches. However, to answer the question of which merge strategy
>> would work best for us I think I need to actually set this up and have a
>> play with it to see how it all pans out using the various options available.
> 
> Yes, it is easy to get into academic discussions of setups, but in
> practice you need to find a workflow that is smooth for your team.
> 
> On one web-based project I work on, we have a setup like this (which is
> very centralized):
> 
>   - a central repo resides on a development server with two branches,
>     "master" and "production"
>   - each developer clones the repo with a working tree
>   - some developers develop directly on 'master' if they have small
>     changes, or only work on one thing at a time; other developers use
>     topic branches to work on simultaneous changes
>   - any developer can push to master; it is expected that your code is
>     in a reasonable state, since it will now be consumed by other
>     developers. Anything that has made it into master is considered
>     published and should not be rebased. It is up to developers whether
>     they want to rebase their work before publishing or to simply merge.
>   - some developers communicate directly with each other: "hey, check
>     out branch 'foo' in my repo" or "what do you think of this patch?"
>   - The live site has a repo cloned from the central repo, pointing at
>     "production".
>   - there is a test site with a repo cloned from the master.
>     Occasionally the master branch is pulled and tested. If it passes,
>     it is pushed to the "production" branch. In addition, small
>     immediate fixes can go onto "production", tested, and then pushed to
>     the central repo's "production"
> 
> So this is not necessarily using the distributed nature of that much,
> but it allows those developers who aren't very comfortable with SCMs to
> stick to a "pull, hack, push" workflow. And those who want to can do
> more interesting things if it helps them.
> 

Thanks for this, it's very useful to read examples of workflows in
actual use. In fact, I was thinking the other day that it would be good
to have a site that acts as a directory of many different workflows,
including descriptions of how they work, how you actually go about
setting it up and using it day to day (i.e. lists of commands for each
role/task) and the pros/cons that it provides. I reckon that would help
newbies out quite a bit (if only for the examples). I've seen a few
individual examples of workflow but nothing like a comprehensive set of
them.

> -Peff

Thanks!

-- 

Russ