Starting with GIT

BASIC COMMANDS TO MANAGE GIT

git add adds file contents to the staging area.

$ git status -s

?? README

?? hello.rb

So right now we have two untracked files. We can now add them.

$ git add README hello.rb

Now if we run git status again, we'll see that they've been added.

$ git status -s

A  README

A  hello.rb

OK, so now if we edit one of these files and run git status again, we will see something odd.

$ vim README

$ git status -s

AM README

A  hello.rb

git status view the status of your files in the working directory and staging area.

As you saw in the git add section, in order to see what the status of your staging area is compared to the code in your working directory, you can run the git status command. Using the -s option will give you short output. Without that flag, the git status command will give you more context and hints. Here is the same status output with and without the -s. The short output looks like this:

$ git status -s

AM README

A  hello.rb

git diff shows diff of what is staged and what is modified but unstaged.

$ vim hello.rb

$ git status -s

 M hello.rb

$ git diff

diff --git a/hello.rb b/hello.rb

index d62ac43..8d15d50 100644

--- a/hello.rb

+++ b/hello.rb

@@ -1,7 +1,7 @@

 class HelloWorld

   def self.hello

-    puts "hello world"

+    puts "hola mundo"

   end

 end

git diff --cached show diff of staged changes.

The git diff --cached command will show you what contents have been staged. That is, this will show you the changes that will currently go into the next commit snapshot. So, if you were to stage the change to hello.rb in the example above, git diff by itself won't show you any output because it will only show you what is not yet staged.

$ git status -s

 M hello.rb

$ git add hello.rb 

$ git status -s

M  hello.rb

$ git diff

$ 

If you want to see the staged changes, you can run git diff --cached instead.

$ git status -s

M  hello.rb

$ git diff

$ 

$ git diff --cached

diff --git a/hello.rb b/hello.rb

index d62ac43..8d15d50 100644

--- a/hello.rb

+++ b/hello.rb

@@ -1,7 +1,7 @@

 class HelloWorld

   def self.hello

-    puts "hello world"

+    puts "hola mundo"

   end

 end

git diff HEAD show diff of all staged or unstaged changes.

If you want to see both staged and unstaged changes together, you can run git diff HEAD - this basically means you want to see the difference between your working directory and the last commit, ignoring the staging area. If we make another change to our hello.rb file then we'll have some changes staged and some changes unstaged.

Here are what all three diff commands will show you:

$ vim hello.rb 

$ git diff

diff --git a/hello.rb b/hello.rb

index 4f40006..2ae9ba4 100644

--- a/hello.rb

+++ b/hello.rb

@@ -1,7 +1,7 @@

 class HelloWorld

+  # says hello

   def self.hello

     puts "hola mundo"

   end

 end

$ git diff --cached

diff --git a/hello.rb b/hello.rb

index 2aabb6e..4f40006 100644

--- a/hello.rb

+++ b/hello.rb

@@ -1,7 +1,7 @@

 class HelloWorld

   def self.hello

-    puts "hello world"

+    puts "hola mundo"

   end

 end

$ git diff HEAD

diff --git a/hello.rb b/hello.rb

index 2aabb6e..2ae9ba4 100644

--- a/hello.rb

+++ b/hello.rb

@@ -1,7 +1,8 @@

 class HelloWorld

+  # says hello

   def self.hello

-    puts "hello world"

+    puts "hola mundo"

   end

 end

git diff --stat show summary of changes instead of a full diff.

If we don't want the full diff output, but we want more than the git status output, we can use the --stat option, which will give us a summary of changes instead. Here is the same example as above, but using the --stat option instead.

$ git status -s

MM hello.rb

$ git diff --stat

 hello.rb |    1 +

 1 files changed, 1 insertions(+), 0 deletions(-)

$ git diff --cached --stat

 hello.rb |    2 +-

 1 files changed, 1 insertions(+), 1 deletions(-)

$ git diff HEAD --stat

 hello.rb |    3 ++-

 1 files changed, 2 insertions(+), 1 deletions(-)

git commit records a snapshot of the staging area.

Now that you have staged the content you want to snapshot with the git add command, you run git commit to actually record the snapshot. Git records your name and email address with every commit you make, so the first step is to tell Git what these are.

$ git config --global user.name 'Your Name'

$ git config --global user.email you@somedomain.com

Let's stage and commit all the changes to our hello.rb file. In this first example, we'll use the -m option to provide the commit message on the command line.

$ git add hello.rb 

$ git status -s

M  hello.rb

$ git commit -m 'my hola mundo changes'

[master 68aa034] my hola mundo changes

 1 files changed, 2 insertions(+), 1 deletions(-)

Now we have recorded the snapshot. If we run git status again, we will see that we have a "clean working directory", which means that we have not made any changes since our last commit - there is no un-snapshotted work in our checkout.

$ git status

# On branch master

nothing to commit (working directory clean)

If you leave off the -m option, Git will try to open a text editor for you to write your commit message. In vim, which it will default to if it can find nothing else in your settings, the screen might look something like this:

# Please enter the commit message for your changes. Lines starting

# with '#' will be ignored, and an empty message aborts the commit.

# On branch master

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#

# modified:   hello.rb

#

~

~

".git/COMMIT_EDITMSG" 9L, 257C

git commit -a automatically stage all tracked, modified files before the commit.

If you think the git add stage of the workflow is too cumbersome, Git allows you to skip that part with the -a option. This basically tells Git to run git add on any file that is "tracked" - that is, any file that was in your last commit and has been modified. This allows you to do a more Subversion style workflow if you want, simply editing files and then running git commit -a when you want to snapshot everything that has been changed. You still need to run git add to start tracking new files, though, just like Subversion.

$ vim hello.rb

$ git status -s

 M  hello.rb

$ git commit -m 'changes to hello file'

# On branch master

# Changed but not updated:

#   (use "git add <file>..." to update what will be committed)

#   (use "git checkout -- <file>..." to discard changes in working directory)

#

# modified:   hello.rb

#

no changes added to commit (use "git add" and/or "git commit -a")

$ git commit -am 'changes to hello file'

[master 78b2670] changes to hello file

 1 files changed, 2 insertions(+), 1 deletions(-)

git reset undo changes and commits.

git reset is probably the most confusing command written by humans, but it can be very useful once you get the hang of it. There are three specific invocations of it that are generally helpful.

git reset HEAD unstage files from index and reset pointer to HEAD.

First, you can use it to unstage something that has been accidentally staged. Let's say that you have modified two files and want to record them into two different commits. You should stage and commit one, then stage and commit the other. If you accidentally stage both of them, how do you un-stage one? You do it with git reset HEAD -- file. Technically you don't have to add the -- - it is used to tell Git when you have stopped listing options and are now listing file paths, but it's probably good to get into the habit of using it to separate options from paths even if you don't need to.

Let's see what it looks like to unstage something. Here we have two files that have been modified since our last commit. We will stage both, then unstage one of them.

$ git status -s

 M README

 M hello.rb

$ git add .

$ git status -s

M  README

M  hello.rb

$ git reset HEAD -- hello.rb 

Unstaged changes after reset:

M hello.rb

$ git status -s

M  README

 M hello.rb

Now you can run a git commit which will just record the changes to the README file, not the now unstaged hello.rb.

When you run git reset without specifying a flag it defaults to --mixed. The other options are --soft and --hard.

git reset --soft moves HEAD to specified commit reference, index and staging are untouched.

The first thing git reset does is undo the last commit and put the files back onto the stage. If you include the --soft flag this is where it stops. For example, if you run git reset --soft HEAD~ (the parent of the HEAD) the last commit will be undone and the files touched will be back on the stage again.

$ git status -s

M  hello.rb

$ git commit -am 'hello with a flower'

[master 5857ac1] hello with a flower

 1 files changed, 3 insertions(+), 1 deletions(-)

$ git status

# On branch master

nothing to commit (working directory clean)

$ git reset --soft HEAD~

$ git status -s

M  hello.rb

This is basically doing the same thing as git commit --amend, allowing you to do more work before you roll in the file changes into the same commit.

git reset --hard unstage files AND undo any changes in the working directory since last commit.

The third option is to go --hard. This command discards your staged changes and the changes in your working directory. In other words: it resets your staging area and working directory to the state they were in at the given commit. This is the most dangerous option and is not working directory safe. Any changes not committed will be lost.

$ git status

# On branch master

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#

# modified:   README

#

# Changes not staged for commit:

#   (use "git add <file>..." to update what will be committed)

#   (use "git checkout -- <file>..." to discard changes in working directory)

#

# modified:   README

#

$ git reset --hard HEAD

HEAD is now at 5857ac1 hello with a flower

$ git status

# On branch master

nothing to commit (working directory clean)

In the above example, while we had both changes ready to commit and ready to stage, a git reset --hard wiped them out. The working tree and staging area are reset to the tip of the current branch or HEAD.

You can replace HEAD with a commit SHA-1 or another parent reference to reset to that specific point.

git rm remove files from the staging area.

git rm will remove entries from the staging area. This is a bit different from git reset HEAD which "unstages" files. To "unstage" means it reverts the staging area to what was there before we started modifying things. git rm on the other hand just kicks the file off the stage entirely, so that it's not included in the next commit snapshot, thereby effectively deleting it.

By default, a git rm file will remove the file from the staging area entirely and also off your disk (the working directory). To leave the file in the working directory, you can use git rm --cached .

git mv git rm --cached orig; mv orig new; git add new

Unlike most other version control systems, Git does not track file renames. Instead, it just tracks the snapshots and then figures out what files were likely renamed by comparing snapshots. If a file was removed from one snapshot and another file was added to the next one and the contents are similar, Git figures it was most likely a rename. So, although the git mv command exists, it is superfluous - all it does is a git rm --cached, moves the file on disk, then runs a git add on the new file. You don't really need to use it, but if it's easier, feel free.

In its normal form the command is used to delete files. But it's often easier to just remove the files off your disk and then run git commit -a, which will also automatically remove them from your index.

git branch list, create and manage working contexts.

git checkout switch to a new branch context.

The git branch command is a general branch management tool for Git and can do several different things. We'll cover the basic ones that you'll use most - listing branches, creating branches and deleting branches. We will also cover basic git checkout here which switches you between your branches.

git branch list your available branches

Without arguments, git branch will list out the local branches that you have. The branch that you are currently working on will have a star next to it and if you have coloring turned on, will show the current branch in green.

$ git branch

* master

This means that we have a 'master' branch and we are currently on it. When you run git init it will automatically create a 'master' branch for you by default, however there is nothing special about the name - you don't actually have to have a 'master' branch but since it's the default that is created, most projects do.

git branch (branchname) create a new branch

So let's start by creating a new branch and switching to it. You can do that by running git branch (branchname).

$ git branch testing

$ git branch

* master

  testing

Now we can see that we have a new branch. When you create a branch this way it creates the branch at your last commit so if you record some commits at this point and then switch to 'testing', it will revert your working directory context back to when you created the branch in the first place - you can think of it like a bookmark for where you currently are. Let's see this in action - we use git checkout (branch) to switch the branch we're currently on.

$ ls

README   hello.rb

$ echo 'test content' > test.txt

$ echo 'more content' > more.txt

$ git add *.txt

$ git commit -m 'added two files'

[master 8bd6d8b] added two files

 2 files changed, 2 insertions(+), 0 deletions(-)

 create mode 100644 more.txt

 create mode 100644 test.txt

$ ls

README   hello.rb more.txt test.txt

$ git checkout testing

Switched to branch 'testing'

$ ls

README   hello.rb

So now we can see that when we switch to the 'testing' branch, our new files were removed. We could switch back to the 'master' branch and see them re-appear.

$ ls

README   hello.rb

$ git checkout master

Switched to branch 'master'

$ ls

README   hello.rb more.txt test.txt

git branch -v see the last commit on each branch

If we want to see last commits on each branch we can run git branch -v to see them.

$ git branch -v

* master      54b417d fix javascript issue

  development 74c111d modify component.json file

  testing     62a557a update test scripts

git checkout -b (branchname) create and immediately switch to a branch

In most cases you will be wanting to switch to the branch immediately, so you can do work in it and then merging into a branch that only contains stable work (such as 'master') at a later point when the work in your new context branch is stable. You can do this pretty easily with git branch newbranch; git checkout newbranch, but Git gives you a shortcut for this: git checkout -b newbranch.

$ git branch

* master

$ ls

README   hello.rb more.txt test.txt

$ git checkout -b removals

Switched to a new branch 'removals'

$ git rm more.txt 

rm 'more.txt'

$ git rm test.txt 

rm 'test.txt'

$ ls

README   hello.rb

$ git commit -am 'removed useless files'

[removals 8f7c949] removed useless files

 2 files changed, 0 insertions(+), 2 deletions(-)

 delete mode 100644 more.txt

 delete mode 100644 test.txt

$ git checkout master

Switched to branch 'master'

$ ls

README   hello.rb more.txt test.txt

You can see there how we created a branch, removed some of our files while in the context of that branch, then switched back to our main branch and we see the files return. Branching safely isolates work that we do into contexts we can switch between.

If you start on work it is very useful to always start it in a branch (because it's fast and easy to do) and then merge it in and delete the branch when you're done. That way if what you're working on doesn't work out you can easily discard it and if you're forced to switch back to a more stable context your work in progress is easy to put aside and then come back to.

git branch -d (branchname) delete a branch.

If we want to delete a branch (such as the 'testing' branch in the previous example, since there is no unique work on it), we can run git branch -d (branch) to remove it.

$ git branch

* master

  testing

$ git branch -d testing

Deleted branch testing (was 78b2670).

$ git branch

* master

git push (remote-name) (branch-name) pushing to a remote branch.

$ git push origin master

git push (remote-name) (local-branch-name):(remote-branch-name) renaming branches.

git push (remote-name) :(branchname) delete a remote branch.

When you're done with a remote branch, whether it's been merged into the remote master or you want to abandon it and sweep it under the rug, you'll issue a git push command with a specially placed colon symbol to remove that branch.

$ git push origin :tidy-cutlery

To git@github.com:octocat/Spoon-Knife.git

 - [deleted]         tidy-cutlery

In the above example you've deleted the "tidy-cutlery" branch of the "origin" remote. A way to remember this is to think of the git push remote-name local-branch:remote-branch syntax. This states that you want to push your local branch to match that of the remote. When you remove the local-branch portion you're now matching nothing to the remote, effectively telling the remote branch to become nothing.

git tag (tag-name) :(branchname) creating a tag name.

git push --tags origin pushin tag names.

$ git tag tag_name

$ git push --tags origin

How to remove a commit that is already pushed to the remote GIT repository

1. First of all we hace to locate the hash we have to go:

$ git log --pretty=oneline

2. We have to indicate the hash we have to go:

$ git reset --hard 66d7fa3e1391e2ec3bca47d0a7be9809a4017553

3. And finally we have to update to the remote repository:

$ git push origin master --force

NOTE: You have to change the config file in the remote server with this option:

...

[receive]

        denyNonFastforwards = false

...

How to rename a tag already pushed to a remote git repo

If you’ve added a tag, pushed to remote and realised that you’d named it wrong. eg. 2.50 instead of 2.51 . To change it back you would need to add a new tag and push it,

$ git tag new_tag old_tag

$ git push --tags

Then delete the old tag from remote and local

$ git push origin :refs/tags/old_tag

$ git tag -d old_tag

But remember this can screw around with other people local repositories if they’ve already pulled before you make the change. So be careful!

How to rename a commit massages of past commits

To change a commit message of the most recent (unpushed) commit, you can simply use:

$ git commit --amend -m 'new message'

To change messages of (unpushed) commits further in the past:

$ git rebase -i [COMMIT BEFORE THE FIRST YOU WANT TO EDIT]

Mark all messages to be changed with "edit".

Git will start the rebasing and stop at every marked commit. For each of those, do a

$ git commit --amend -m 'new message'

$ git rebase --continue

Then, force pushing again:

$ git push origin master --force

VERY IMPORTAN

If you lost accidentally the log of your remote repository you will have to follow the following steps:

$ git reflog

$ git reset --hard your_lost_commit's_id