Learn Git Branching
pcottle.github.io
pcottle.github.io
In my experience, as long as you hold onto the cognition that a repository is a collection of files and commits are, in effect, diffs, git won't ever really make sense, since none of what it does could be feasibly implemented with diffs. It's actually much simpler than that, hence the name.
When I first started learning git, I had only experience with SVN and Perforce. Both typically led to egregious practices (branches are directories?) and actual merges were rare (rather, you manually merged and just made a new commit). I felt they were a huge hindrance and were actually constantly in my way, a sort of mandatory bookkeeping I had to maintain.
When I started working for a company that heavily uses git, I buckled down and read through pro git (available at http://git-scm.com/book for free), the user guide (https://www.kernel.org/pub/software/scm/git/docs/user-manual...), and the man pages of the commands I was using. One day it just clicked and all made sense, and it was the only logical solution to SCM. Now I can't live without git. In my personal projects, step #1 is to git init a new repo. In working, git is never in my way, and rather provides me with incredibly powerful tools for massively increasing my productivity through workflows that just aren't possible under SVN/P4.
Watch this video: http://vimeo.com/14629850
I've not ordered yet another weird database, why is it on my bill?
If you're on Subversion and ignore that the repo is basically a counted list of big file trees with properties on the nodes, you won't get branching right.
If (FSM forbid) you're on MKS and ignore that it keeps per-file version histories somewhere in the belly of the expensive server, you'll try silly things like creating new files on a branch.
And for Git, you learn that there are commits, trees and refs.
You don't. But if your mental model of how Git works is wrong – and if you came from another SCM system, it probably is – figuring out how Git actually works is the only way to fix it.
The whole point of git is the weird database. I'd tell you to go use another system if you don't like it, but that's not really an option anymore. So I'd instead just suggest that you do yourself a favor and spend an hour learning about it; you'll be far more effective as a result.
You personally do not have to understand all the parts, but you do need someone to build a SCM for you out of it and tell you what the parts are then.
However it is no longer true. Git is very much a SCM and is being developed as an independent tool, not just as a platform for tool development.
That makes it harder to introduce Git in an organization where nobody brings along enough Git experience to design all that upfront.
I understand what you're saying: I have helped some friends who were that guy trying to bring it in.
I'd always heard that said about the tool we used today to point out "It does way too much for a single SCM, you have to find what YOU need a SCM to do and use that".
I need lots of branches amongst my team. I tried to use Perforce branching and I found out I was pounding nails into my eyeballs.
I'd be surprised if any of the other SCMs that can do what git does have significantly different models of behavior. I know Darcs is quite similar (though it can be a little smarter about merges sometimes).
- It is an overkill for a small project with a central repository - what we usually have, leading to a large conceptual overhead.
Why it became popular in the first place? a) Linus, b) It's pretty easy and pain-free when you have a single-person project that doesn't branch much.
As I worked through this website (which is great by the way) it struck me that by focusing so clearly and completely on the underlying object graph that's supposed to lead to nirvana for learners, the site does a great job of highlighting the obtuseness of Git's command set.
I mean you've got a great honking big graph on the screen, another big honking graph to the side, and you're asked to "make this one look like that one". This should be so easy now that you see it - essentially drag and drop albeit with text commands - it should have almost no pedagogical value (if you built a model in Lego then it would literally be child's play). Yet even having identified what I needed to move and where I wanted to move it, the challenge remained - what is the weirdly named command I must type to make that (and only that) happen? Which way round are the arguments again? (eg. 'git rebase', to move stuff from the current branch to somewhere else, versus 'git merge', to 'move' stuff from somewhere else to the current branch, always gives me pause.)
I'm most grateful to this website for telling me about 'git branch -f <branch name> <destination>' as a way to repoint a ref. To think that all this time I thought you had to checkout the ref, reset --soft, then maybe checkout again if you wanted to get HEAD back to where it started (all the while dealing with the side effects and possible conflicts with your working directory). None of the tutorials or books I had read, such as "git for computer scientists", "Think Like a Git", or the "Pro Git" book ever mentioned (correct me if I'm wrong) that fairly fundamental operation despite schooling me quite thoroughly in the "think of the object graph" mindset. (Yeah it's in the man page, but then there's a lot of stuff in the manpage so noticing it is the problem there. And I tend to assume any option named "--force" is something that I shouldn't be messing with. Why not "git repoint-ref" or "git move-ref" anyway? Git has so many top-level commands already, it doesn't seem like they're worried about polluting that namespace.)
But, if the people involved are proficient using it and the learning is not a issue, there is still git goodness to be used (or even dare I to say: to enjoy).
I find myself using A LOT of local branches while developing. Not only they are cheap to make/destroy, it's pretty flexible to manipulate it (ya, rebase).
When you are comfortable with things like staging, stashing, branching, rebasing, rebasing interactively, using -p (patch) in commands and reflog git enables you wonderful workflows (note the plural).
There is this gap between awkardness/frustation and power/enjoyment when using git. Tools like these help people jump it.
I strongly disagree. All my projects use git and the majority of them are small with a central repository.
As someone who learned Git and SVN at the same time, I think git has an undeservedly bad reputation. There are many workflows where Git is much easier to grasp conceptually (initializing a new repo, branching, how do I work on an airplane?) I think people who are comfortable with SVN tend to forget that, other than the confusion around staging, it's easier for rank beginners to learn the basics of Git than the basics of SVN.
(Just now I am converting some scientific collaborators to use Mercurial for small projects. Still, for code I use Git... but mainly because of GitHub.)
It's like power tools for my code.
Until a better way comes along, we still mostly develop software with code in a bunch of files. And we still mostly depend on the shitty filesystem for all that. That's what Git does. Frees me to some extent from the shitty filesystem.
Personally I think Git is always useful but I reap far, far more dividends on big projects where the forking, branching and merging give me support for software engineering as the social craft that it is.
Generally, Git can be summarized fairly easily, but when it comes to workflow, I think you just need the practice of doing it.
Branches and submodules make a bunch of sense, but I think it's deceptive and fruitless to describe the whole fetch-pull-rebase-reset business as something that's trivially simple and logical.
I don't know if those four followed from one flow of thinking, or whether they just co-exist as option for handling your project.
The Django Book is one of my favourite programming guides ever, because it describes why the different features and shortcut functions exist, which gives a flow (chart) to the tools available to you in Django.
With Git, I often just see a lot of users bickering over whether they should rebase, pull, and whatnot, and people start sounding like they just advocate their own workflow instead of a logic intrinsic to how Git was designed.
Oh, wait, sorry!
You can pick up monads in half a day (on the example of IO, List, Maybe, Reader, State), but learning git takes several days of reading books and docs and then months of practice.
Monads would also NOT bite your behind if you skip understanding the underlying theory. Git will.
The problems that we have run into usually stem from hand-jammed scripts that attempt to automate the process of creating release branches (hotfixes, etc). Not to mention the original workflow using git wasn't to actually use feature branches (either locally or remotely) and just use it like Subversion.
Since we've introduced the git-flow scripts this has become easier because we can "abstract away" all of those operations. But this really just moves the cheese because then a majority of your developers may not understand how and what to actually do if presented with a real issue with git.
In particular, the appendix on internal representations made everything make sense. Once you understand that commits form a DAG with a set (branches, tags, HEAD) of roots, it makes a lot of sense. Or so I thought.
"This talk is not for the Git beginner, but a more advanced look at "weird internals stuff" and obscure commands that will reveal a sort of internal API that is there for you to use and help expose you to certain intrinsic software design insights that can be had from looking at Git at this level."
The Git Cheatsheet (interactive)
I wouldn't go that far myself, however I do feel that Git has a LOT of features and becomes the "Jack-of-all-trades-master-of-none", if you will.
Since I've grokked it properly, I'm now happy with it, but there are things I'm still not okay with doing (`git bisect' being one).
Please check out the demo of the app if you haven't seen it yet: pcottle.github.com/learnGitBranching/?demo
It explains most of the operatons and gives you a sense of how to start and stop lessons.
I'm also working on getting lessons for origin commands (git push, pull, fetch, etc). You can see a short demo of that functionality here: http://pcottle.github.io/learnGitBranching/?NODEMO&command=g...
But a lot of it is broken still, so it's strictly a WIP
What I am missing though is:
- examples and motivation,
- commands on the right (to see them all the time and learn eventually), or example files in the folder,
- on the level-chooser - 'empty' for starting just with the command line (e.g. for level-building).
That is it implicitly assumes that someone knows what are branches, why to use them, when to use them (and when - not). E.g. 'lightweight' as a feature, not - goal. Sure, this tutorial assumes some level... but if one is a master at branching, then one does not need to learn it from a graphical tutorial.
I'm noticing that the Merging in Git level (level 3?) gives you 6 steps to complete, but then complains that you didn't do it in 5. Is this a bug?
That being said, I think I'll resubmit when I get the origin lessons in place (WIP here:) http://pcottle.github.io/learnGitBranching/?NODEMO&command=g...
And then hopefully I'll be out of everyone's hair forever.
You can even make lessons to share with friends... That's amazing! Next step: make user contributed lessons archive!
On the on-chance that you are trolling:
You go to the repository and raise an issue regarding the fact that there is no obvious "This site requires JavaScript" message for those who access the site without JS.
https://github.com/pcottle/learnGitBranching/issues/107
You're welcome.
You can always use "show solution" to see what we are using as the benchmark. Command discovery is a bit hard to communicate in this app -- I added the helper bar at the bottom for the most common commands but I only have so many pixels...
I am working on origin lessons right now (see link above) but I could actually make a file staging version if necessary. What other gaps of knowledge do you think it could fill?
Awesome stuff
In what was is it too complicated for most use cases? Most use cases involve "code being worked on by multiple people", in which case it has seen great success.
And as a bonus, you're using a tool that has the capacity to grow as necessary.