Git

From XOmB wiki
Jump to: navigation, search
This page is part of a series on Guides.

git is a Source Control Management system written by Linus Torvalds. If this means nothing to you, check out Source Control Management.

For reasons why we use git vs svn, check out the git-svn comparison or Why Git Is Better Than X. They say it better than we could.

Installing Git

Git is in most distributions' repositories by now. We use Arch Linux, so we type

# pacman -S git

to install it. If you were on Ubuntu or another Debian based distribution, you'd use

# apt-get install git-core

instead.

Using Git

Basic Git Usage

  • Starting a new project
git init

You shouldn't need to do this for XOmB, as we have a repo you should be cloning from, but if you were starting a project of your own, you'd do this. It's kept here for completeness' sake.

  • Setting up your account:

This makes sure that everything on GitHub gets attributed nicely.

git config --global user.name="githubusername"
git config --global user.email="yourgithubemail"
  • To check out a copy of the source from GitHub:

With an account:

Go to GitHub, click on the fork button. Then type this:

git clone git@github.com:YOURUSERNAME/xomb.git

Without an account:

git clone git://github.com/xomboverlord/xomb.git
  • To add files to the staging area:

To add a file by name:

git add file_name

To add all files you've edited:

git add .
  • To see what's been staged and what hasn't:
git status
  • To commit all files from the staging area to your repository:

Using your favorite editor to type your commit message:

git commit

Adding a message on the command line:

git commit -m "message goes here"
  • To commit all files that have changed directly while skipping the staging area:
git commit -a
  • To add your local changes to your GitHub account:
git push
  • To get the latest and greatest from the XOmB repository:
git pull
  • To roll back changes that you've made:
git reset --hard

To roll back to two commits ago, you'd do this:

git reset --hard HEAD~2

Note that reset will make you lose those commits...if you want to save them, peel them off into a branch:

git branch branch_name
git reset

Now the branch_name branch will contain things as they were before you rolled them back.

More Advanced Use-Cases

  • Creating a branch
git branch branch_name
  • Listing branches
git branch
  • Switching to a different branch
git checkout branch_name
  • Merging two branches together

Let's use these two branches as an example:

$> git branch
* master
  experimental
$>

Let's merge experimental into master:

git merge experimental

rebasing:

Let's say that the official 'master' branch of a project has been developing nicely:

A-B-C

At commit C, you make a branch, and work on it.

A-B-C
     \
      D-E

However, implementing D and E takes some time, and extra work has been done on master in the meantime.

A-B-C-F
    \
     D-E

Now our branch doesn't have these changes from F. So what we need to do is move the base of our branch to the latest changes. We do this with the 'rebase' command. This takes the previous diagram, and turns it into this:

A-B-C-F
       \
        D-E

Which means that now our branch has all of the newest changes. Here's how you do this:

git rebase master

Note: for safety's sake, only use rebase on your private, local branches. If you want to share stuff with others, you'll want to be merging.

  • Follow someone else' branches

Let's say that Wilkie wants to follow my experimental branch, as we're collaborating on a new project. He needs to do this:

git branch experimental
git checkout experimental
git remote add steve git://github.com/steveklabnik/xomb.git
git fetch steve

Now he has a branch of mine.

My Git Workflow

Let's assume that I'm just starting to work on XOmB. I've forked the project on my GitHub account, and I've already done the configuration bit I talked about earlier. I'd do something like this:

$> git clone git@github.com:steveklabnik/xomb.git (1)
$> cd xomb/src
$> git branch experimental (2)
$> git checkout experimental (3)
$> git branch (4)
  master
* unstable
$> git branch awesome-feature (5)
$> git checkout awesome-feature (6)
$> vim super/awesome/file (7)
$> make clean iso (8)
$> sudo xm create ~/domu.hvm (9)
$> sudo xm destroy XOmB-steve (10)
$> git add super/awesome/file (11)
$> git status (12)
... tons of stuff ...
$> git commit -m "Implemented super awesome feature in super/awesome/file. It's super awesome." (13)
$> git checkout unstable (14)
$> git merge awesome-feature(15)
$> git branch cool-feature (16)
...continue to develop each feature in its own branch, merging back into unstable as needed
$> sudo xm create ~/domu.hvm (17)
$> sudo xm destroy XOmB-steve
...okay, by now, I've determined that my feature works, and is ready to be included in my master branch
$> git checkout master (18)
$> git merge experimental (19)
$> git push origin master (20)

And then log onto GitHub and click on the 'pull request' button to ask xomboverlord to merge my cool new features back into the main repository.

Some further explanation:

  1. Clone the original repository from my GitHub to my machine.
  2. Create a branch named 'experimental'.
  3. Move into that branch.
  4. Double check which branch I'm in. I'm not a trusting person.
  5. Create a branch called 'awesome-feature'.
  6. Move into that branch.
  7. Edit the file and add some sweet code.
  8. Compile up my changes.
  9. Since I don't make mistakes, my code compiles cleanly, and it's time to test it out!
  10. My test ran flawlessly, so kill the xen instance.
  11. Let's add that file to git's staging area
  12. Examine everything, if it's changed, and if it's staged or not. Make sure I'm committing what I want to be comitting.
  13. Commit my changes, while adding an eloquent soliloquy as my commit message.
  14. Switch back into the unstable branch.
  15. Merge the feature branch into the unstable branch.
  16. Make another branch called 'cool-feature' for my cool new feature.
  17. Once all of my features are merged into experimental, I need to test it out!
  18. Move into the master branch
  19. Merge experimental branch into the master
  20. Push the changes I've made to my master branch back to GitHub. I could just do a 'git push' to push the branches, if I wanted those to be publicly available.

Branches are super awesome like this. You can isolate your new features into their own branch, and merge everything together. This ensures that even if you screw things up pretty bad, your master stays stable, your experimental tests how each feature works together, and each branch tests each feature in isolation. And if your feature isn't working out, just kill that branch and start another one over!

Git Resources

Cheat Sheets

General Links

Blogs