Re: Workflow question

[Junio C Hamano <gitster@pobox.com>]

Russ Brown <pickscrape@gmail.com> writes:

> 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?

You actually never checkout "remote tracking branches".

You can be in two states, either you are on a branch (meaning,
if you create a commit, the new commit will have the current tip
commit of that branch as its first parent and will become the
new tip commit of that branch), or you aren't on _any_ branch.

The latter state is often affectionately called "detached HEAD"
state.

This is primarily useful for sightseeing.  Sometimes people
would want to check out a commit that is not a tip of any
branch.  The most typical one is "I want to have a checkout of
version 2.6.17", and people call that (loosely) as "checking out
a tag".  In the same way, you can "checkout a remote tracking
branch" (but if you want to be anal in terminology, you never
"check out a tag" nor "check out a remote branch"---you are
detaching your HEAD at the named commit (which could be the one
pointed at by the tag, or the one at the tip of your remote
tracking branch).

Detached HEAD state allows you to make further commits and
merges.  Because git allows you to create a new branch from the
current commit (i.e. whatever HEAD points at, be it on any
branch or detached) without losing local changes in the index
nor the work tree, this is often handy for doing quick fixups and
experiments --- you first start on detached HEAD and if it turns
out not to be so "quick" fixup, at that point you can create a
real branch so that you can continue working on it without
losing track.

> 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.

"Everyday" might be a good starting point for catalogs of
workflows for people playing various roles.