View Source

h1. Table Of Contents
{toc}

h1. Branching, Merging & Development strategy (from _+[StackOverflow|http://stackoverflow.com/questions/21848/switch-branch-names-in-git]+_)

{tip}One good strategy during development *is to never works directly on master branch*.{tip}

Always we have to create a new branch for new code:
{noformat}
> git checkout -b topic/topic_name master
{noformat}

From there, I can push out the changes to public repositories:
{noformat}
> git push pu topic/topic_name
{noformat}

Or eventually just merge it back in master branch:
{noformat}
> git checkout master && git merge topic/topic_name
{noformat}

If you truly need to go back to an older point in time and set that as your master, you can rename the current branch to something else and then check out an older version to be your master:
{noformat}
> git branch -m master junk
> git co -b master old_sha1_value
{noformat}

h1. How To: Switch “origin” of your GIT repository

{noformat}
> git remote set-url <remote name eg:origin> <new git url>
{noformat}


h1. How To: Stashing your changes (_+[original post|http://book.git-scm.com/4_stashing.html]+_)

While you are in the middle of working on something complicated, you find an unrelated but obvious and trivial bug. You would like to fix it before continuing. You can use *git stash* to save the current state of your work, and after fixing the bug (or, optionally after doing so on a different branch and then coming back), *unstash* the work-in-progress changes.

{noformat}
$ git stash save "work in progress"
{noformat}

This command will save your changes away to the stash, and reset your working tree and the index to match the tip of your current branch. Then you can make your fix as usual.

{noformat}
... edit and test ...
> git commit -a -m "your comment"
{noformat}

After that, you can go back to what you were working on with git stash apply:

{noformat}
> git stash apply
{noformat}

h2. Stash Queue

You can also use stashing to queue up stashed changes.

{noformat}
> git stash list
stash@{0}: WIP on book: 51bea1d... fixed images
stash@{1}: WIP on master: 9705ae6... changed the browse code to the official repo
{noformat}

Then you can apply them individually with

{noformat}
> git stash apply stash@{1}
{noformat}

Clear out the list with ''.
{noformat}
> git stash clear
{noformat}



h1. How to: Delete a remote Git tag

Probably you don’t need to do this often (if ever at all) but just in case, here is how to delete a tag from a remote Git repository.

If you have a tag named ‘mytag’ then you would just do this:

{noformat}
> git tag -d mytag
> git push origin :refs/tags/mytag
{noformat}

That will remove ‘mytag’ from the remote repository (E.g Github).

h1. How to: svn project as git repository

h3. Checkout
{noformat}
> git svn clone <svn repo url>
{noformat}

h3. Commit your changes
{noformat}
> git svn dcommit
{noformat}

h3. Update your working copy

{noformat}
> git svn rebase
{noformat}

h1. How to: Keeping a git fork in sync with the forked repo.

When you fork a git repo, probably you would like to keep in sync the forked repo with the original one. This is how I do it.

{noformat}
> git remote add <repo name> <git url>
{noformat}

h3. Fetch

{noformat}
> git fetch <repo name>
{noformat}

h3. This will create a branch, so then you just have to merge back:
{noformat}
> git checkout master
> git merge <repo name>/master
{noformat}

h3. Commit those new changes:

{noformat}
> git commit -a -m "Sync to fork master"
{noformat}

h1. How To: Tagging

h2. Create the tag:

{noformat}
> git tag -a 1.0 -m'release 1.0'
{noformat}

h2. push your tag to the remote repository:

{noformat}
> git push --tags
{noformat}

h1. How to: Convert from Subversion to Git
* _+[Article from paul dowman blog|http://pauldowman.com/2008/07/26/how-to-convert-from-subversion-to-git/]+_