Dev Tools


Development Flow (my view):

  1. When starting a new change, create a new branch for it: git branch [branch_name] and then REMEMBER to switch to this branch: git checkout [branch_name] (You can do this in one step using git checkout -b [branch_name]).
  2. After doing the change (with many commits in the middle), tag the change: git tag [tag_name]
  3. Checkout the master branch and merge the new branch into it: git merge [branch_name]

Working with One Remote Repository (i.e. github or a gitolite server you created for yourself). This is the typical case since most of us won’t be using git’s distributed capabilities. It is also easy:

  1. Clone your repository: git clone [full URL of your repository]. For example git clone If you created your own repository, you probably know the URL. Otherwise, someone gave it to you so just put it in there.
  2. Change what you want to change in your repository, add to index and commit.
  3. Push your changes back to the remote repository: git push. Since there is only one repository you don’t have to tell git where to go; This was already stored when you cloned. The cloned repository is named origin by default.

Branch Management:

  1. Create a new branch based on the current branch: git branch [branch_name].
  2. Checkout a branch: git checkout [branch_name].
  3. Create and checkout a branch based on the current branch: git checkout -b [branch_name].
  4. Merge a branch into the current branch: git merge [branch_name]. This command will try to apply all changes in [branch_name] in the current branch. Hopefully, you will not have any conflicts (conflicts are hard to manage and I hate having to manage them…). It will also create a new commit (in your current branch) containing the result of the merge.
  5. Comparing: Find differences between two branches: git diff [branch1]..[branch2] will give you ALL the changes. Only useful when these are few; git log [branch1]..[branch2] will show you the logs between the two branches; and finally git shortlog [branch1]..[branch2] gives a summary of these same logs.
  6. Stashing: saves the current state of the working directory and index, and reverts the directory to the last commit of the current branch (the HEAD). It is simple to use: git stash. After stashing, you can re-apply the stashed changes anywhere – independent of where you stashed them. Just do git stash pop. This command will also remove the stash from git’s memory (you can have more than one stash at any time, but if managing branches is already a thing most programmers don’t like to do, managing stashes is probably much worse.

Remote Repository Management:

  • Fetch the changes that have occurred in the remote default repository: git fetch. Note that this command WILL NOT merge the changes into the local repository, but will only fetch them.

Git Version Names:

  • HEAD: the latest commit in the current branch.
  • [refname]^: first parent to the given refname. For example HEAD^ is the first parent of the latest commit. [refname]^{n}: the {n}th parent of the given refname. Note that these are single generation parents, because a commit ing it can have more than one parent.
  • [refname]~: the first generation parent of the given refname, following only first parents. This is equivalent to HEAD^. [refname]~{n} is the {n}th generation parent of the given refname following only first parents. So HEAD~3 is equivalent to HEAD^^^.


  • Suppose you forgot to create a branch and are in the middle of a change, but you don’t want this change to be part of the master branch. This site explains how to solve this problem (Broken link). What you do is commit the changes and create a new branch on this commit (git branch [branch_name]). Then you checkout the master branch (git checkout master) and move it to a previous commit: git reset --hard [sha1_of_previous_commit].
  • If you miss-typed the name of a branch (or created a branch and started to work on the wrong thing), you can rename the branch: git branch -m [old_branch_name] [new_branch_name]. If you just want to delete the branch: git branch -D [branch-name]. If you have already pushed the branch you have to go a step further and remove the old branch from your remote repository with git push origin :[old_branch_name] (note that you have to state the name of the remote repository, even if it is the default one). Many thanks to Richard for this answer in stackoverflow.
  • If you committed a change, but the commit log came out bad (spelling mistakes or otherwise nothing good), you can change the commit log using git commit --amend -m "New commit message" (thanks Denis Bueno and stackoverflow). Note that this change “rewrites history”, so if you pushed the commit and then decided to amend it, you will have to merge the remote branch before you can push again.


This article shows how to (manually) fork one of your projects in Github. I had to do this because a team of students is starting to work with me on a project and I didn’t want to give them the minimal chance to damage my repository. So I forked it and now they work on the fork. If something good comes out of it, i’ll also have to learn how to pull the changes (and I’ll post it here, of course). UPDATE 05/06/2012: After following the tutorial a couple of times, the result was a new repository which had only one branch instead of all the branches in the original repository… Not what I expected. So what I did was create a new remote repository in my local repository and executed push –all

Good tutorial on how to install gitolite.


Deploy to local filesystem using maven wagon plugin:

Another interesting source of git information can be found here.

Vogella’s tutorial on Maven, Tycho and Wagon:

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.