Section on branching #12
Conversation
|
Oh my gosh I am SO EXCITED to see you doing this. Nitpick: there's a typo, "experement" "Using git checkout "name_of_branch" (without the quotation marks!) will let you switch between branches whenever you have the need." <-- This will fail if people have uncommitted changes. Needs to be noted, and tutorial steps need to make sure to walk people through the commit. (Or have them try to switch before they've committed, and then acknowledge & explain the error -- actually that is probably the best strategy!) Conceptually, I'm not quite sure if this wants to be an explanation, illustrated with commands, or a walkthrough tutorial, with some explanation. I guess the original tutorial is a hybrid itself, so maybe that works :) I think breaking the "Local branching" section into some smaller, more task-focused steps would help. Love the screencaps. |
|
Your comments are well taken. I will continue to work on this, breaking the "Local Branching" section into smaller steps. |
|
I think this is a pretty good start, Andromeda's comment about uncommitted changes is a good point though. I think it'd be nice to give people something to do too, like the original tutorial where they added their name to a list, but I'm not sure what it could be. Maybe something like "look at learn-git-resources.mdown and put a + beside any resource you found useful"? Just an idea. |
|
In terms of stuff to do, since it's a branching tutorial, I'm in favor of making a gh-pages branch and putting some HTML on it, so you can show it off on the web. (not sure if this should be "switch to gh-pages branch of libcodeyear repo, add stuff to a central page" or "make your own gh-pages branch in your forked repo, now you have a personal page". latter might be funner, former means we can give them an html template to edit) |
|
So I don't think gh-pages makes a good example case because A) it's an orphan branch, which is unique & requires some special flags on the I do agree we should do something with gh-pages, but maybe that's the next step after this tutorial? Once people have branching skills then they can play with pages. |
|
Good points! In that case I like the idea of gh-pages as a step 3 project, on people's own repos, so they have their own pages to show off. Which leads to the question of, what would it be useful or fun to have people merge in? Which I think also leads pretty quickly to the question of merge conflicts. If we ask people to do what they do for tutorial stage 1 (edit a common file), we have to address handling merge conflicts. If we ask people to contribute separate files, I think we can sidestep that, but we have to provide some guidance as to what their unique file should be (and it's also a slightly new thing since before they only edited an existing file). I think I'd prefer the avoid-merge-conflicts option for now, to reduce the complexity that people have to face before achieving victory at something. Possibly as a step 2, after they've done a basic branch-and-merge, we can have them merge something which is guaranteed to cause a conflict, and walk them through resolving it. |
|
What do we think about pulling this in & continuing to work on it? I like the direction it's headed in & I think there was consensus around first building up some branching skills & then moving onto more complex issues like gh-pages/merge conflicts. |
|
Sorry! I've been distracted by other projects all week. I still intend to make suggested changes, but if you think it is going in the right direction, and pulling it in will allow others to help make it better, I'm for that. I'll still be jumping in to make some edits over the weekend, too. |
|
Oh, no worries, I was afraid we'd scared you away! If you're planning to work on it over the weekend I say we hold off on pulling it in for now, I have other ideas to work on & wouldn't get to anything soon. |
Added a new section under "Getting Started" called gethub_branching.mdown. Section is under development, but is a complete tutorial on local branching.