LearnGitBranching now has lessons on git fetch, push, and pull

[xxbondsxx]

http://pcottle.github.io/learnGitBranching/?remoteDemo&defaultTab=remote

[asciimo]

I really like the approach and the visuals. I almost never think of Git visually and this opens a whole new dimension for me. I'm looking forward to discover techniques and workflows outside of my everyday patterns. Thank you for sharing this with the world.

However, the interface is often confusing. For example, I'm not sure what to do with the avalanche of dialogs at the beginning. So I just navigated to the earliest '1' button and pressed that. Also, the "goal" graph at the beginning of each exercise disappears, and I don't know how to recall it. Finally, the goal objectives can't be displayed at the same time that the console is active, and "help level" restarts the entire level description. It would be nice if both the goal graph and the list of objectives were both visible during the exercise. (If this is indeed possible, I obviously missed it.)

[xxbondsxx → asciimo]

Thanks for the feedback asciimo -- there are definitely some tough UX challenges with this type of app. Some comments:

0) you should only get one dialog with the link above, and that's the dialog that shows the new levels 1) the avalanche of dialogs at the beginning are the "lesson" for each level. They basically introduce the concept and describe how to solve the level -- sorry maybe it's not clear that every lesson comprises of "slides + solve" 2) the goal graph only disappears if you click it -- you can bring it back with "show goal" (which is a command in your history when the level starts) 3) you can view just the objective again with "objective" 4) when the goal graph comes up, you can still type into the console. it just might be a hard to see the results of your commands (this is the biggest issue and I haven't found a way to resolve it... :-/

Anyways, let me know if you have ideas on how to make the app more usable / newcomer friendly. It's hard for me because I don't have a pair of fresh eyes...

[joeblau]

I beat the main game and now you guys are adding more levels! Argh, I'm trying to get work done here!

[xxbondsxx → joeblau]

Thanks Joe, took me a while since some of the remote commands get some obscure / complicated. And testing them means setting up random repros and pushing / pulling.

The two highlights for me are that "git fetch origin :foo" actually just makes a new branch named foo, and "git push origin :bar" deletes the branch bar on origin. It basically means "push nothing to bar" and "fetch nothing to foo".

Why git has that as a valid command... who knows

(btw I love gitignore! I recommend it all the time, especially for big web frameworks like django)

[officialjunk]

i feel like my flow is always different than these types of tutorials:

  git checkout master
  git pull
  git checkout -b my-working-branch
  git add <files>
  git commit -m "some description"
  git add <files>
  git commit -m "review comments or other changes"
  git checkout master
  git checkout -b my-working-branch-squashed 
  git merge --squash my-working-branch
  git commit
  git checkout master
  git pull
  git cherry-pick <hash from squashed commit>
  git push

this way i can push a single commit that may have been comprised of multiple commits on my working branch. i haven't come across a tutorial that does it this way. am i doing it wrong. this flow works well for me.

[xxbondsxx → officialjunk]

No this is totally fine. I'd say the slightly more rare thing about this workflow is the fact that you squash multiple commits for a feature together. At least at larger companies it's nice to maintain a series of commits that lead to a feature (rather than getting a giant commit that plops the feature down with no sense of how it slowly developed).

I added support for merge --no-ff since a fair number of people like that workflow: http://pcottle.github.io/learnGitBranching/?NODEMO&command=g...

but maybe --squash should be next

[wging → xxbondsxx]

I work in a team of about 10 at a large company and it's convention to squash. The alternative is turning a potentially very messy history into something we'd care to look at two months from now. This doesn't seem worthwhile, especially since you now have a situation where some commits on master are intermediate, unshippable states.

What am I missing?

[prezjordan → xxbondsxx]

In that case, I just pop into the reflog and undo the squash.

[xxbondsxx → prezjordan]

True, although ideally reflog is just a backup in case you make a mistake (and not an integrated part of your workflow).

What I've found surprising is just how different workflows can be from project to project (or company to company). Some developers are die-hard about preserving history at the expense of the graph, whereas others are straight-line purists (and don't even accept merge commits on the remote).

I actually have some limited support for "git checkout -" to go back, but I should get around to making a legit reflog...

[wging → officialjunk]

What is the advantage of creating my-working-branch-squashed over just

    git checkout master
    git merge --squash my-working branch
    git commit

You have to `git diff --staged` or `git diff master^` at some point to check that what you've done is right, but you would be doing that anyway with my-working-branch-squashed.

[rnbrady]

This is totally awesome!