Git

Git , is a distributed revision control and source code management (SCM) system with an emphasis on speed. Initially designed and developed by Linus Torvalds for Linux kernel development, Git has since been adopted by many other projects. Every Git working directory is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server.

Stages

Git Repo Stages

This is the main thing to remember about Git if you want the rest of your learning process to go smoothly.
Git has three main states that your files can reside in:

• Committed,
  Committed means that the data is safely stored in your local database.
• Modified,
  Modified means that you have changed the file but have not committed it to your local database yet.
• Staged,
  Staged means that you have marked a modified file in its current version to go into your next commit snapshot.

This leads us to the three main sections of a Git project: the Git directory, the working directory, and the staging area.

• Git directory
  The Git directory is where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer.
  The directory named .git in the project directory of the local copy is the Local Git Repository.
• Working directory
  The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify.
  The checkout directory (containing the .git directory) is the working directory.
• Staging area
  The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.
  As said is located inside the .git directory.

Basic Workflow

The basic Git workflow goes something like this:

1. Modify files in your working directory.
2. Stage the files, adding snapshots of them to your staging area.
3. Commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.
4. Push, which takes the committed files into the remote repo.

Setup

To setup git follow the steps below.

Username

First you need to tell git your name, so that it can properly label the commits you make.

 # Sets the default name for git to use when you commit.
 $ git config --global user.name "harm"

Email

Git saves your email address into the commits you make. We use the email address to associate your commits with your GitHub account. <syntaxhighlight lang="bash" >

1. Sets the default email account for git when you commit

$ git config --global user.email "h.frielink@<you-server-name>" </syntaxhighlight>

Cheat Sheet

Always handy are Cheat Sheets .

Information & Config

Information		Tools
Status Repo	git status	Store away (stash)	git stash
		Configuration	git config

Creation, Addition & Removal

Create & Clone		Add & Remove
Create new repo	git init	Add changes to INDEX	git add <filename>
Clone local repo	git clone /path	Add all changes to INDEX	git add *
Clone remote repo	git clone username@host:/path/to/repo	Remove / Delete	git rm <filename>

Commit & Branches

Commit & Synchronize		Branches
Commit changes	git commit -m "Message"	Create new branch	git checkout -b <branch> i.e.: git checkout feature-x
Push changes to remote repo	git push origin master	Switch to master branch	git checkout master
Connect local repo to remote repo	git remote add origin <server>	Delete branch	git branch -d <branch>
Update local repo with remote changes	git pull	push branch to remote repo	git push origin <branch>

Merging & Tagging

Merge		Tagging
Merge changes from another branch	git merge <branch>	Create tag	git tag <tag> <commit-ID>
View changes between 2 branches	git diff <src-branch> <trg-branch>	Get commit IDs	git log

Inside .git folder

`-- refs `-- tags </syntaxhighlight>

<syntaxhighlight lang="text"> .
-- applypatch-msg	-- commit-msg	-- post-commit	-- post-receive	-- post-update	-- pre-applypatch	-- pre-commit	-- pre-rebase	-- prepare-commit-msg	`-- update
`-- exclude
-- HEAD	`-- refs
COMMIT_EDITMSG (file): The last commit’s message. Not actually used by Git at all, but for your reference after you made a commit. FETCH_HEAD (file): The SHAs of branch/remote heads that were updated during the last git fetch. HEAD (file): The current ref that you’re looking at. In most cases it’s probably refs/heads/master. ORIG_HEAD (file): When doing a merge, this is the SHA of the branch you’re merging into. MERGE_HEAD (file): (Optional) When doing a merge, this is the SHA of the branch you’re merging from. MERGE_MODE (file): (Optional) Used to communicate constraints that were originally given to git merge to git commit when a merge conflicts, and a separate git commit is needed to conclude it. Currently --no-ff is the only constraints passed this way. MERGE_MSG (file): (Optional) Enumerates conflicts that happen during your current merge. RENAMED-REF (file): Still trying to track this one down. From a basic grep through the source, it seems like this file is related to errors when saving refs. branches (folder): Contains the branching information?? config (file): Contains settings for this repository. Specific configuration variables can be dumped in here (and even aliases!) What this file is most used for is defining where remotes live and some core settings, such as if your repository is bare or not. description (file): If you’re using Gitweb or firing up git instaweb, this will show up when you view your repository or the list of all versioned repositories. Is an old setting. hooks (folder): Git comes with a set of script that you can automatically run at every meaningful git phase. Those scripts, called hooks, can be run before/after a commit/rebase/pull… The name of the script dictate when to execute it. An example of a useful pre-push hook would be to test that all the styling rules are respected to keep consistency in the remote (the distant repository). index (file): The staging area with meta-data such as timestamps, file names and also SHAs of the files that are already wrapped up by Git. info (file): Relatively uninteresting except for the exclude file that lives inside of it. We’ve seen this before in the ignoring files article, but as a reminder, you can use this file to ignore files for this project, but beware! It’s not versioned like a .gitignore file would be. logs (folder): Contains history for different branches. Seems to be used mostly with the reflog command. objects (folder): Git’s internal warehouse of blobs, all indexed by SHAs. packed-refs (folder): Packs away dormant refs, this is not the definitive list of refs in your repository (the refs folder has the real ones!) Take a look at gitster’s comment to see more information on this. refs (folder): The master copy of all refs that live in your repository, be they for stashes, tags, remote tracking branches, or local branches.

See also

External

• GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Over eight million people use GitHub to build amazing things together.
  • Guides GitHub, Basic Information (Guides) to Git and the implementation of Git on GitHub.
  • Help GitHub, The best place to look with a massive number of categories and help. A must if you are looking for something.
• Cloudforge, Free Git repository Website for all your code.

Internal

• GitHub, information on the GitBub, How to use, How to get information and more.

Tutorials

• Tutorial, Introduction to git 1.5.1. or newer.
• Read-Write, Github for beginners.