Skip to content
adryitan edited this page Mar 13, 2011 · 13 revisions

Get your repository

This will be a quick how to get used to git workflow commands.

First of all, register to GitHub

Then go to emesene/emesene and click on the “Fork” button.

Now you’ve got a YOURNAME/emesene repository.
You’ll see a link named “YOUR Clone Url”.

Copy that link, open a terminal and type:
git clone LINK emesene

Great, now you have a directory called “emesene” with your project inside.

Code! (commit)

Now you’re ready to code. Suppose you want to implement the feature “foobar”.

Then type git checkout -b foobar, it will create a new branch called “foobar” and switch to it.
Now, just code and, when you think it is right to, commit with: git commit -a (purists will hate me, but this is just a short intro, right?).

In the commit message, follow this simple git convention: first line is long no more than 50 characters, with a short summary. If more explanation is needed you should leave a blank line, then enter your long description on 79-chars limiter lines.
Example:


This is a good commit.

It is good because it implements lot of long-wanted features, like foo and bar.
Furthermore, no lolcatz were killed when doing this.

Better commits

You should not push what is not needed. Doing git commit -a, instead, commits just everything. This, often, is bad.
You’d better use git add and, most of all, git add -p
-p stays for “patch”: it will ask, for each “block” of code which you could commit, if you really want to commit it.
It is very simple to use, and will make you more responsible about what you’re commiting.

If you want to make sure about what you’re commiting, use git diff --cached, it will display the ready-to-commit changes.
Also, I like to use git commit -v, which displays the diff as a comment, so that I can view it while writing the commit message.

Keeping history tidy (rebase)

For a good guide on rebasing, I suggest you to read rebase chapter on ProGit

Why rebasing? What’s the problem with just pushing?

Well, actually you could just push to your repository.
But we’d like to easily pull changes from your repo to emesene’s one.
It actually can’t be done if the history has diverged somewhere in the past.
Indeed, we have two kind of situations:

  • BAD
o--o--O--o--o--o <-- origin
 \
  a--b--c <-- mywork
  • GOOD
o--o--o <-- origin
       \
        o--o--o <-- mywork

Well, if we’re in the good one, a push will just “append” commits. So good.
But if we’re in the bad one, we’ll have to merge. A merge can fail. And even if it doesn’t fail, it can’t ensure that it will work just fine.

How can I know if I’m in a bad situation?

I suggest you to run gitk or gitk --all. The commit tree should be self-explainatory.

What should I do if I’m in a bad situation?

rebase.
Just do (we’ll assume that “emesene” is your name for http://github.com/emesene/emesene repo)
git rebase emesene

Further readings

git user manual: rebase

Hai to the world (push)

Work in progress

Sometimes your feature is not still complete, but you still want to make the world know about it.

git push origin foobar will upload the branch “foobar” to your GitHub repository.
You can view it at the URL https://github.com/YOURNAME/emesene/tree/foobar
So, you’ll have TWO branches on your GitHub repo: master and foobar.
When you go to https://github.com/YOURNAME/emesene it will display “master” by default, but you can browse to “foobar” easily.

Feature complete

When your work on that feature is finally done, you should merge the changes in the master branch:

git checkout master
git merge foobar

If you behave like a good boy, it shouldn’t report conflicts. However, conflicts could happen…

git push origin master will upload the changes you just did to your GitHub master branch.

You could keep your foobar branch (if you like “feature-branch” development style, which I won’t discuss here), or you could delete it:

git push origin :foobar will remove foobar branch from GitHub
git branch -d foobar will remove the branch foobar from your local repo, too.

Getting updates

You heard on the ML that mariano is doing something really great on his repository, and you absolutely want
to put your hands on it.

git remote add mariano git://github.com/marianoguerra/emesene.git (it’s just an alias)

Now, make sure you don’t have uncommited changes! (git status is your friend)

git pull mariano will merge mariano’s repo into yours. If there are conflicts, solve it or git reset --hard

Clone this wiki locally