Skip to content

Instantly share code, notes, and snippets.

@vaichidrewar
Created October 27, 2013 21:18
Show Gist options
  • Save vaichidrewar/7187994 to your computer and use it in GitHub Desktop.
Save vaichidrewar/7187994 to your computer and use it in GitHub Desktop.
Git Basics : git init git status git add octocat.txt git commit -m "Add cute octocat story" git add '*.txt' git commit -m "Add all the octocat txt files" git remote add origin https://github.com/try-git/try_git.git git push -u origin master git pull origin master git diff HEAD git ad octofamily/octodog.txt git diff --staged git reset octfamily/o…
To initialize a Git repository in current directory, type the following command:
git init
Type the git status command to see what the current state of our project is:
git status
Create file octocat.txt in current directory and 'git status' will show it as untracked file.
To tell Git to start tracking changes made to octocat.txt, we first need to add it to the staging area by using git add.
git add octocat.txt
Now that will be included in 'changes to be commited' list. The files listed in 'changes to be committed' are in the Staging area, and they are not in our repository yet. We could add or remove files from the stage before we store them in the repository.
To store our staged changes we run the commit command with a message describing what we've changed. Let's do that now by typing:
git commit -m "Add cute octocat story"
We can add all the new files using a wildcard with git add. Don't forget the quotes! This add the txt files from subdirectories too.
git add '*.txt'
git commit -m "Add all the octocat txt files"
So we've made a few commits. Now let's browse them to see what we changed.
Fortunately for us, there's git log. Think of Git's log as a journal that remembers all the changes we've committed so far, in the order we committed them.
Remote Repositories :
Great job! We've gone ahead and created a new empty GitHub repository for you to use with Try Git at https://github.com/try-git/try_git.git. To push our 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.
Go ahead and run git remote add with the options below:
git remote add origin https://github.com/try-git/try_git.git
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
When you start to get the hang of git you can do some really cool things with hooks when you push.
For example, you can upload directly to a webserver whenever you push to your master remote instead of having to upload your site with an ftp client. Check out Customizing Git - Git Hooks (http://git-scm.com/book/en/Customizing-Git-Git-Hooks) for more information.
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:
git pull origin master
Differences:
Uh oh, 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 Differences:
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 add octofamily/octodog.txt
Good, now go ahead and run git diff with the --staged option to see the changes you just staged. You should see that octodog.txt was created.
git diff --staged
Resetting the Stage:
So now that octodog is part of the family, octocat is all depressed. Since we love octocat more than octodog, we'll turn his frown around by removing octodog.txt.
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
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
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
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.
git commit -m "Remove all the cats"
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.
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
Deleting the branch:
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
The Final Push:
Here we are, at the last step. I'm proud that you've made it this far, and it's been great learning Git with you. All that's left for you to do now is to push everything you've been working on to your remote repository, and you're done!
git push
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment