Russ Brown <pickscrape@xxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
