GIT – All I need to know

Start Repo

#git init

Git Status check

#git status

GIT Terms
staged:
Files are ready to be committed.
unstaged:
Files with changes that have not been prepared to be commited.
untracked:
Files aren’t tracked by Git yet. This usually indicates a newly created file.
deleted:
File has been deleted and is waiting to be removed from Git.

Add a newly created file to git repo:

#git add filename

Tips
add all:
You can also type “git add .” ,The dot represents the current directory, so everything in it, and everything beneath it gets added.

git reset:

You can use git reset <filename> to remove a file or files from the staging area.

#git status

This will list the new added file but which is being added to the staging area and not in repo yet.

Staging Area:
A place where we can group files together before we “commit” them to Git.
Commit
A “commit” is a snapshot of our repository. This way if we ever need to look back at the changes we’ve made (or if someone else does), we will see a nice timeline of all changes.

Commit the Changes

#git commit -m "commit description"

Add multiple files to git

#git add '*.txt'

Okay, you’ve added all the text files to the staging area. Feel free to run git status to see what you’re about to commit.

Wildcards:
We need quotes so that Git will receive the wildcard before our shell can interfere with it. Without quotes our shell will only execute the wildcard search within the current directory. Git will receive the list of files the shell found instead of the wildcard and it will not be able to add the files inside of the octofamily directory.

Check History of git commits

#git log

Remote Repositories
go ahead and create a new empty GitHub repository to use with. https://github.com/try-git/try_git.git
To push the local repo to the GitHub server we’ll need to add a remote repository

This command takes a remote name and a repository URL, which in your case is https://github.com/try-git/try_git.git.

#git remote add origin https://github.com/try-git/try_git.git

Tip
Git doesn’t care what you name your remotes, but it’s typical to name your main one origin.
It’s also a good idea for your main repository to be on a remote server like GitHub in case your machine is lost at sea during a transatlantic boat cruise or crushed by three monkey statues during an earthquake.

Pushing Remotely

The push command tells Git where to put our commits when we’re ready, and boy we’re ready. So let’s push our local changes to our origin repo (on GitHub).

The name of our remote is origin and the default local branch name is master. The -u tells Git to remember the parameters, so that next time we can simply run git push and Git will know what to do. Go ahead and push it!

#git push -u origin master

Pulling Remotely

Let’s pretend some time has passed. We’ve invited other people to our github project who have pulled your changes, made their own commits, and pushed them.

We can check for changes on our GitHub repository and pull down any new changes by running:

Differences
looks like there has been some additions and changes to the octocat family. Let’s take a look at what is different from our last commit by using the git diff command.

In this case we want the diff of our most recent commit, which we can refer to using the HEAD pointer.

#git diff HEAD

Staged Differenceshttp://blog.xceptance.com/2013/10/
Another great use for diff is looking at changes within files that have already been staged. Remember, staged files are files we have told git that are ready to be committed.

Let’s use git add to stage octofamily/octodog.txt, which I just added to the family for you.

#git diff --staged
output:
diff --git a/octofamily/octodog.txt b/octofamily/octodog.txt
new file mode 100644
index 0000000..cfbc74a
--- /dev/null
+++ b/octofamily/octodog.txt
@@ -0,0 +1 @@
Success!

Commit Etiquette:
You want to try to keep related changes together in separate commits. Using ‘git diff’ gives you a good overview of changes you have made and lets you add files or directories one at a time and commit them separately.

Resetting the Stage
You can unstage files by using the git reset command. Go ahead and remove octofamily/octodog.txt.

#git reset octofamily/octodog.txt

Undo
git reset did a great job of unstaging octodog.txt, but you’ll notice that he’s still there. He’s just not staged anymore. It would be great if we could go back to how things were before octodog came around and ruined the party.

Files can be changed back to how they were at the last commit by using the command: git checkout — <target>. Go ahead and get rid of all the changes since the last commit for octocat.txt

#git checkout -- octocat.txt

Tip
The ‘–‘
So you may be wondering, why do I have to use this ‘–‘ thing? git checkout seems to work fine without it. It’s simply promising the command line that there are no more options after the ‘–‘. This way if you happen to have a branch named octocat.txt, it will still revert the file, instead of switching to the branch of the same name.

Branching Out
When developers are working on a feature or bug they’ll often create a copy (aka. branch) of their code they can make separate commits to. Then when they’re done they can merge this branch back into their main master branch.

We want to remove all these pesky octocats, so let’s create a branch called clean_up, where we’ll do all the work:

#git branch clean_up

Branches are what naturally happens when you want to work on multiple features at the same time. You wouldn’t want to end up with a master branch which has Feature A half done and Feature B half done.
Rather you’d separate the code base into two “snapshots” (branches) and work on and commit to them separately. As soon as one was ready, you might merge this branch back into the master branch and push it to the remote server.

Switching Branches
Great! Now if you type git branch you’ll see two local branches: a main branch named master and your new branch named clean_up.

You can switch branches using the git checkout <branch> command. Try it now to switch to the clean_up branch:

#git checkout clean_up

Tip
Remove all the things!
Removing one file is great and all, but what if you want to remove an entire folder? You can use the recursive option on git rm:

git rm -r folder_of_cats

This will recursively remove all folders and files from the given directory.

Removing All the Things
Ok, so you’re in the clean_up branch. You can finally remove all those pesky octocats by using the git rm command which will not only remove the actual files from disk, but will also stage the removal of the files for us.

You’re going to want to use a wildcard again to get all the octocats in one sweep, go ahead and run:

#git rm '*.txt'

Commiting Branch Changes
Now that you’ve removed all the cats you’ll need to commit your changes.
Feel free to run git status to check the changes you’re about to commit

#git commit -m "Remove all the cats"

Tip
The ‘-a’ option
If you happen to delete a file without using ‘git rm’ you’ll find that you still have to ‘git rm’ the deleted files from the working tree. You can save this step by using the ‘-a’ option on ‘git commit’, which auto removes deleted files with the commit.
git commit -am “Delete stuff”

Switching Back to master
Great, you’re almost finished with the cat… er the bug fix, you just need to switch back to the master branch so you can copy (or merge) your changes from the clean_up branch back into the master branch.

Go ahead and checkout the master branch:

#git checkout master

Preparing to Merge
Alrighty, the moment has come when you have to merge your changes from the clean_up branch into the master branch. Take a deep breath, it’s not that scary.

We’re already on the master branch, so we just need to tell Git to merge the clean_up branch into it:

#git merge clean_up

Keep Things Clean
Congratulations! You just accomplished your first successful bugfix and merge. All that’s left to do is clean up after yourself. Since you’re done with the clean_up branch you don’t need it anymore.

You can use git branch -d <branch name> to delete a branch. Go ahead and delete the clean_up branch now:

#git branch -d clean_up

Force delete
What if you have been working on a feature branch and you decide you really don’t want this feature anymore? You might decide to delete the branch since you’re scrapping the idea. You’ll notice that git branch -d bad_feature doesn’t work. This is because -d won’t let you delete something that hasn’t been merged.
You can either add the –force (-f) option or use -D which combines -d -f together into one command.

The Final Push
Here we are, at the last step.

#git push

Done.

Extras

Cloning an Existing Repository
If you want to get a copy of an existing Git repository — for example, a project you’d like to contribute to — the command you need is git clone. If you’re familiar with other VCS systems such as Subversion, you’ll notice that the command is clone and not checkout. This is an important distinction — Git receives a copy of nearly all data that the server has. Every version of every file for the history of the project is pulled down when you run git clone. In fact, if your server disk gets corrupted, you can use any of the clones on any client to set the server back to the state it was in when it was cloned (you may lose some server-side hooks and such, but all the versioned data would be there — see Chapter 4 for more details).

You clone a repository with git clone [url]. For example, if you want to clone the Ruby Git library called Grit, you can do so like this:

$ git clone git://github.com/schacon/grit.git

That creates a directory named grit, initializes a .git directory inside it, pulls down all the data for that repository, and checks out a working copy of the latest version. If you go into the new grit directory, you’ll see the project files in there, ready to be worked on or used. If you want to clone the repository into a directory named something other than grit, you can specify that as the next command-line option:

$ git clone git://github.com/schacon/grit.git mygrit

That command does the same thing as the previous one, but the target directory is called mygrit.

Staging Modified Files
Let’s change a file that was already tracked. If you change a previously tracked file called benchmarks.rb and then run your status command again, you get something that looks like this:

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   README
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#
#   modified:   benchmarks.rb
#

The benchmarks.rb file appears under a section named “Changes not staged for commit” — which means that a file that is tracked has been modified in the working directory but not yet staged. To stage it, you run the git add command (it’s a multipurpose command — you use it to begin tracking new files, to stage files, and to do other things like marking merge-conflicted files as resolved). Let’s run git add now to stage the benchmarks.rb file, and then run git status again:

$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   README
#   modified:   benchmarks.rb
#

Both files are staged and will go into your next commit. At this point, suppose you remember one little change that you want to make in benchmarks.rb before you commit it. You open it again and make that change, and you’re ready to commit. However, let’s run git status one more time:

$ vim benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   README
#   modified:   benchmarks.rb
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#
#   modified:   benchmarks.rb
#

What the heck? Now benchmarks.rb is listed as both staged and unstaged. How is that possible? It turns out that Git stages a file exactly as it is when you run the git add command. If you commit now, the version of benchmarks.rb as it was when you last ran the git add command is how it will go into the commit, not the version of the file as it looks in your working directory when you run git commit. If you modify a file after you run git add, you have to run git add again to stage the latest version of the file:

$ git add benchmarks.rb
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   README
#   modified:   benchmarks.rb

If you want to see what you’ve staged that will go into your next commit, you can use

#git diff --staged

Summarised!

How to enable git for a Dir

cd /tmp/unni
git init
git pull

New File to Repo

echo hihih > hi.txt
git add .
git commit -m "Test file"
git push

Remove File

git rm filename
git commit -m "File Deleted"
git push

More On Git : http://blog.xceptance.com/2013/10/

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s