Version ControlThis is an open series in which Hacker Public Radio Listeners can share their knowledge and experience of version or revision control systems such as Bazaar, Mercurial, Subversion, CVS and Git.
A git rebase is like a git merge done through rose-coloured glasses.
You can see it for yourself by doing this little experiment. Assuming the
alicedirectory is a valid git repository:
$ cd alice $ echo "foo" >> rebase.episode $ git add rebase.episode ; git commit -m 'begin rebase episode' $ git checkout -b monsters $ git branch * monsters master $ echo "ghoul" >> ghoul.txt $ git add ghoul.txt ; git commit -m 'ghoul' $ git checkout master $ echo "rogue" >> rogue.txt $ git add rogue.txt ; git commit -m 'rogue' $ git checkout monsters $ echo "dragon" >> dragon.txt $ git add dragon.txt ; git commit -m 'dragon' $ git checkout master $ echo "paladin" >> paladin.txt $ git add paladin.txt ; git commit -m 'paladin'
You have now emulated a bunch of activity on two separate branches of a git repository. Create a copy of the repo so that you can perform two separate git actions.
$ cd .. $ cp -r alice alice-merge $ cp -r alice alice-base
Do an honest merge:
$ cd alice-merge $ git checkout master $ git merge monsters
The log shows you an accurate representation what got merged, and how all those changes came to be:
$ git log --oneline 123456 Merged monsters into master 789101 paladin 112131 dragon 415161 rogue 718191 ghoul 7ef217 begin rebase episode
Now perform a rebase.
$ cd ../alice-base $ git checkout master $ git rebase monsters
The log displays a different story than what really happened.
123456 Merged monsters into master 8e9122 paladin 21d163 rogue 912a3f dragon 51c098 ghoul 7ef217 begin rebase episode
Better? Worse? YOU DECIDE!
Gitolite provides an admin a centralised interface, in the form of a configuration file, to make managing users, user permissions, repos, and user and repo groups easy. It abstracts Git users from UNIX users by defining a user by public keys, and manages permissions down to the branch-level. And better yet, it is itself managed over Git.
Proper documentation is available on Gitolite.com
A sample post-receive git hook:
#!/usr/bin/tcsh foreach arg ( $< ) set argv = ( $arg ) set refname = $1 end set branch = `git rev-parse --symbolic --abbrev-ref $refname` echo $branch if ( "$branch" == "master" ) then echo "Branch detected: master" echo "Do some stuff here." else if ( "$branch" == "dev" ) then echo "Branch detected: dev" echo "Do something else here." else echo "Do something entirely different here." endif
How do you manage large binary blobs, like pictures or video or sounds, when using git?
In this episode, Klaatu explains two popular options:
Thanks to CapsLok at freesound.org for the sound effect.
Set up your git remotes (‘origin’ and ‘foo’)
Create a new remote (‘all’) entry to encompass the existing targets
Adjust ssh config as needed
git push all HEAD
In this show I talk about the git version control system. I won't give example commands, but I discuss concepts like commits, branches, merging, push and pull, and rebasing. I also talk about the git workflow I use.
I will put some more info on http://johanv.org/node/200.
UTOS (Utah Open Source, http://www.utos.org/) presentation on GIT
Klaatu talks about how to set up, navigate within, commit, and push with git. This is a beginner level howto that will also help you understand SVN and CVS.
You can also download the ogg version of this episode.