On: Git Is Simpler Than You Think

[masnick]

Thanks -- great article. This is the most readable and straight-forward explanation of git's internals that I've seen (and I've read a bunch of articles/books/etc. looking for resources to help others learn git).

I'd also recommend The Git Parable (http://tom.preston-werner.com/2009/05/19/the-git-parable.htm...) for anyone who hasn't read it. Different focus, but also helpful for understanding git's philosophy.

[schleyfox → masnick]

I found git to make a lot more sense personally after reading http://eagain.net/articles/git-for-computer-scientists/ . The git parable is also very good.

[watmough → schleyfox]

So if I have branched from master, onto experimental, and made several experimental changes that I want to actually use, then I can simply type:

    git merge master
    git branch master

from the tip of my experimental branch, and master will be moved up to the tip of the tree?

[natep → watmough]

fr0sty was definitely not tactful, but his commands are correct. Merge always brings the branch you specify onto the commit you are currently on. The branch command either lists branches (when no other arguments, only certain options, are specified) or creates branches. Checkout is the command used to move around between commits in your repository.

Branching and merging is covered pretty well by Pro Git[1]

[1] http://progit.org/book/ch3-2.html

[fr0sty → watmough]

Not at all. Where did you come up with that? That would merge in any commits in master not already in experimental and the next command would fail because a branch 'master' already exists.

To do what you are describing you would do this (or something similar:

    git checkout master; git merge experimental

[watmough → fr0sty]

Thanks, obviously I'm missing some concept somewhere.

[rahoulb → watmough]

The checkout command moves you off the experimental branch and back onto the master branch.

The merge command then takes the commits in experimental that aren't in master and puts them into master.

[watmough → rahoulb]

Thanks, I think I may have been misusing

    git branch [some name]

I'll take a look at some of the suggested tutorials again. Thanks all. That said, I pretty much do straight-ahead main-line development, so this isn't a huge problem right now. I do most of my development after midnight, so there isn't a huge cognitive headroom left...

[losvedir → watmough]

I'm still just getting the hang of git, but I've found this best practices[1] tutorial the most handy to just get started. I needed to play around at this basic level before any of these other more complicated comments started to make sense. Check it out, it's very short.

[1] http://ariejan.net/2009/06/08/best-practice-the-git-developm...

[eLod → masnick]

i found the pro git book a very good reading to understand git for the first time http://progit.org/book/

[re_todd → eLod]

Great book. It really helped me overcome git's learning curve.

[geeksam → masnick]

I've struggled with helping others learn git as well; you can see some of my thinking at (http://think-like-a-git.heroku.com/#1) and (http://confreaks.net/videos/612-cascadiaruby2011-think-like-...). Currently working on a longish standalone website for those who (like me) can't stand to slow down enough to sit through an entire 20-minute video. ;>