LIST BRANCHES:

$ git branch (the current branch is the one that has a “*” on front of its name)

CREATE A BRANCH AND CHANGE TO IT:

$ git checkout -b v1.4 # (that will create a new branch from my current one)

GO BACK TO A BRANCH:

$ git checkout master # (para o branch principal) $ git checkout nome_branch # (para um outro branch)

CREATE A TAG:

$ git tag -a v2.0 -m “Launching version 2.0” # creates a tag named “v2.0” based on the current commit. $ git push –tags # (pushes the tag to the repository) WARNINGS:

• I SHALL NOT CHECKOUT TAGS IF I NEED TO UPDATE ANYTHING ON A TAG. A tag is just a pointer, it does not have any information referring to branches. So, changes on tags checkouts go to a “limbo”.
• IF I NEED TO MAKE CHECKOUT OF A TAG TO MAKE CHANGES ON IT, I MUST CREATE A BRANCH FROM THAT TAG: $ git checkout -b v2.0-fixes v2.0 That will create a branch named “v2.0-fixes” from the tag “v2.0”. Then I make the changes I need on that new branch.

LIST DIFFERENCES BETWEEN 2 BRANCHES:

$ git diff v1.4 master # v1.4: branch01, master: branch02

DELETE A BRANCH:

Locally:

$ git branch -D

Remotelly (in “origin”):

OBS.: CAREFUL HERE - are there other developers working on that same branch? $ git push origin –delete (git >= 1.7.0)

(reference: http://stackoverflow.com/questions/5582208/checkout-git-tag) You create a tag and push it to a repository: $ git tag -a v2.0 -m “Launching version 2.0” # creates a tag $ git push –tags # pushes the tag to the repository When you check out a tag, you get this message: You are in ‘detached HEAD’ state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name HEAD is now at If you try to list the branches, and show which one you’re working at: $ git branch You will get this output:

• (no branch) master WHY THIS HAPPENS AND HOW TO WORK CORRECTLY WITH TAGS AND BRANCHES Why this happens: In git, a tag (like many other things) is what’s called a treeish. It’s a way of referring to a point in in the history of the project. Treeishes can be a tag, a commit, a date specifier, an ordinal specifier or many other things. Now a branch is just like a tag but is movable. When you are “on” a branch and make a commit, the branch is moved to the new commit you made indicating it’s current position. Your HEAD is pointer to a branch which is considered “current”. Usually when you clone a repository, HEAD will point to master which in turn will point to a commit. When you then do something like git checkout experimental, you switch the HEAD to point to the experimental branch which might point to a different commit. When you do a git checkout v2.0, you are switching to a commit that is not pointed to by a branch. The HEAD is now “detached” and not pointing to a branch. If you decide to make a commit now (as you may), there’s no branch pointer to update to track this commit. Switching back to another commit will make you lose this new commit you’ve made. That’s what the message is telling you. How to work correctly with tags and branches: Usually, what you can do is: git checkout -b v2.0-fixes v2.0 This will create a new branch pointer at the commit pointed to by the treeish v2.0 (a tag in this case) and then shift your HEAD to point to that. Now, if you make commits, it will be possible to track them (using the v2.0-fixes branch) and you can work like you usually would. There’s nothing “wrong” with what you’ve done especially if you just want to take a look at the v2.0 code. If however, you want to make any alterations there which you want to track, you’ll need a branch.