git-2 « WordPress.com Tag Feed

Default editor for Git

delboy1978uk — Sun, 02 Sep 2012 00:58:33 +0000

Just created a new site, and went to perform my initial commit to my Git repository, and yuk! Vi, or Vim, appeared! :-s Don’t get me wrong, Vi/Vim is powerful and can do all sorts, but I like Nano, or Pico! Last time this happened I type in a command to change the editor, but what I forgot to add was to make it the GLOBAL default. A slight tweak, and the command looks like this. No more Vi! Awesome

git config --global core.editor "nano"

git reset

robinnagpal — Sat, 18 Aug 2012 07:06:00 +0000

Git provides us with various options for modifying history and one of these is “git reset”. Git reset along with different parameters, can be used for the following

We want to keep the files as same but want to reduce the number of commits
Want our working directory to represent a particular commit
erase or discard the previous commits

To achieve all this and more, git provides us with reset command which takes three types of parameters i.e. “–soft”, “–mixed” and “–hard”

Let’s continue with our previous example to understand this clearly. Currently we have four files in our repository a.txt, b.txt, c.txt and d.txt. We now modify the contents of d.txt

$ echo "Commit 4 in branch 1:before reset" >> d.txt

If we try to print the contents of the file, it looks like this

$ cat d.txt
“Commit 2 in branch 2”
“Commit 3 in branch 2”
Commit 4 in branch 1:before reset

Now let’s create another file e.txt

$ echo "Commit 4 in branch 1:before reset" >> e.txt

Lets see the contents

$ cat e.txt
Commit 4 in branch 1:before reset

Our repository will now look like this

And now let’s add these changes to index

$git add .

We will now try all the reset options one by one

git reset –soft HEAD^: This command will just move the HEAD to previous commit. We could have also used “HEAD~2” or “HEAD~3” depending on where exactly we want to take the HEAD. After executing this command our repository looks like this

So from here we see that our changes are still there in the index, it is only our HEAD, which now points to the previous commit. Also, content of all the files remain the same as it was before i.e. if we print the contents of b.txt
```
$ cat b.txt
“Commit 2 in branch 2”
“Commit 3 in branch 2”
Commit 4 in branch 1:before reset
```

git reset –mixed HEAD^ : This command will move our HEAD to the previous commit and will modify our index to align it with the contents of the previous commit.

$ git reset --mixed HEAD^
Unstaged changes after reset:
M    d.txt

So our repository now looks like this

Here red dot shows the unstaged changes. Let’s check this with the status command

$git status
# On branch master
# 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:   d.txt
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#    e.txt
no changes added to commit (use "git add" and/or "git commit -a")

git reset –hard HEAD^ : This command is going to move the HEAD to the previous commit. Also, it will remove all the staged changes and will show you working directory corresponding to the commit on which you have moved. i.e. the previous commit in our case. After this command, your repository will look like this

This command is irreversible and the you will loose all the changes that are in your index.

List files having conflicts on git

vighnesh1987 — Fri, 17 Aug 2012 20:47:24 +0000

Credit: http://stackoverflow.com/questions/3065650/whats-the-simplest-way-to-git-a-list-of-conflicted-files

Colorize your git output

vighnesh1987 — Fri, 17 Aug 2012 20:28:24 +0000

Add this to your .git/config file to prettify the output that you see when you run `git status`, `git log`, etc

Git Internals - branches

robinnagpal — Sun, 05 Aug 2012 04:05:26 +0000

By reading this post you will have the understanding of the following points

Some useful terminologies
Master
HEAD
Branch
What do we mean by a branch in Git and why is it so easy and fast to create branches in Git
What are Local and Remote branches.
Some commands that help us to create and use branches.

These pointers are going to provide us enough knowledge to use Git branching for our project.

Master
This is the initial branch that is created when you initialize a repository. You can imagine it to be something like trunk that is there is SVN.

HEAD
it is the reference of the current branch you have checked out. This is represented by the “HEAD” file that is present in the .git folder. If you cat the contents of the file you will see something like

ref: refs/heads/master

This tells that our working copy points to the latest commit of master. Suppose you are in a branch “branch_1”, then the contents of the HEAD will be

ref: refs/heads/branch_1

Branch
As we have learned that every commit contains following things

A reference to a single parent commit object, or to two parent commit objects, if that is a merge commit.
Reference to a tree object which further contains various blobs or further tree objects.
Some info regarding the commit i.e. author name, email, commit message etc.

So every individual commit is capable of representing the complete snapshot of the project of the time the commit object was made, and it this commit object that makes the Git branching so easy, cheap and robust.

So a branch is nothing but a 40 character string that contains reference to the commit object.
I can understand that it might have been hard to consume this knowledge till now, but stay will me for some more time, and I can assure you that once you get the understanding of the branching model, you will fall in love with it.

Let’s try to visualize this with diagrams

Suppose we have three commits “mc_1” ,”mc_2” and “mc_3” till now, and all of these are in the master.

We now decide to make a branch “branch_1” from master. To achieve this we execute the following commands

$ git branch branch_1
$ git checkout branch_1

Both of these commands can be combined into one command i.e.

$ git checkout -b branch_1

Now our repository should look something like this

We can now see that our HEAD points to “branch_1”, and we can confirm this by viewing the contents of HEAD file.

$ cat .git/HEAD
ref: refs/heads/branch_1

If we see the contents of folder .git/refs/heads we see the following files

branch_1
master

When we created the branch, a new file “branch_1” was created, which contains the SHA1 id of the “mc_3” commit. This is all what a branch is, i.e. a 40 character string that points to the latest commit in that branch.

Let’s now add and commit something to the branch.

$ echo “Greeting !!” > greeting.txt
$git add greeting.txt
$git commit -m “Our first commit to the branch” .

We now have our first commit in the branch. Below is how our repository looks like now.

Here “bc_1” is the new commit object of the new branch. If we check contents of the file .git/refs/branch_1 , we will see it containing the pointer to our new commit object i.e. contains the SHA1 code of commit object bc_1.

Now let’s come back to the master branch and add something there.

$git checkout master
$echo “Happy Birthday” >wishes.txt
$ git add wishes.txt
$ git commit -m “Our first commit in master after creation of the branch” .

After this commit our repository will look something like this

So, we see how easy it is to make and manage branches in GIT. Once you start working with these branches, you will definitely fall in love with the way Git manages these branches.

Lets try to edit our greeting file and then switch to “branch_1”

$echo “Merry Christmas”>greeting.txt
$git checkout branch_1

When you execute the second command, you get the following error

error: The following untracked working tree files would be overwritten by checkout:
greeting.txt
Please move or remove them before you can switch branches.
Aborting

Git asks to either commit or remove your changes before you switch to any other branch. This scenario seems to be trivial, where we can just commit or file and switch to another branch. But think of a real case scenario, where you will be having multiple file, which you don’t want to commit, nor revert those changes. There is a git utility stash that helps you deal with with these type of scenarios.

Local and Remote Branches
Local branches are what we saw above and remote branches come into picture when you start working in a distributed manner. Since Git is a distributed version control system, you can easily pull and push contents from various team members who have the sane project git repository on their machine. All of this is done by using remote branches.

After reading the above examples you should be able to conceptualize that why is it so fast, easy and cheap to create branches in Git.

Git Internals - .git folder

robinnagpal — Sat, 04 Aug 2012 11:15:48 +0000

If you are one of those 80% of the people who just believe in getting the work done and don’t care about the internals, this blog is not for you. It is not that I am against the people who just believe in getting the work done, but it is that I can’t be one of them.

In this blog post I am going to highlight the way GIT tracks your files and how it maintains the versions of it. After reading these concepts you will have answer to the following questions

Why is GIT called a distributed version control system.
Why creating and switching of branches is so fast in GIT
What happens internally when you commit, make a branch, move your code from one revision to other etc.

Assuming that you have very basic or minimal knowledge of GIT, I am going to discuss some of the common terminologies that are common throughout various version control systems.

Repository this is where all your project is stored. This filesystem/directory has the complete knowledge of all the versions of the files that you want you version control system to track.
Commit this is some kind of snapshot of the files you are tracking at that particular time. To make this snapshot identifiable, versions control systems generally attach some metadata to it.
Branch this is where you decide to work upon a common code in different ways. After you create a branch, each branch is now independent of the other and has its own history, along with a common history of before the time the branch was created.

Now lets get started by creating a repository first

 $git init

Execute this command in the directory you want to be tracked by GIT.

The GIT Repository
Let see the contents of this folder after the execution of above command,

 $ ls -latr

We now see a new directory named .git inside this folder. Let’s see what’s inside this .git folder


refs
info
hooks
HEAD
description
config
branches
objects

Everything that is tracked by GIT is present under this .git folder. This folder includes all the versions of your files, branches of your code, and pre/post scripts that you want GIT to run etc. Description of each of the above mentioned folders/files will help you understand how GIT is so efficient and the way git maintains various versions of the files internally.

Lets one by one see what is the role played by the above files and folders

refs – This folder contains info of all the references to tags, branches, stash, head. Since, currently we have no remote or local branches, or any stash or tags, we will not be able to see all the contents of this directory. However, a typical git repository will have the following contents


heads/
remotes/
tags/
stash

info – This conspicuous part of this directory is the exclude file. We can edit this file to include the patterns of the files we don’t want to commit or to be tracked by GIT.

hooks – This folders contains the scripts that we might wish to hook-in i.e. want to be executed before or after some operation, like we want to perform an operation before a commit, after a commit, after update etc. We can see some sample hooks already present in this folder

applypatch-msg.sample
commit-msg.sample
post-commit.sample
post-receive.sample
post-update.sample
pre-applypatch.sample
pre-commit.sample
pre-rebase.sample
prepare-commit-msg.sample
update.sample

HEAD – This includes the current ref we are looking at. In our case, since we are on the master itself, we see that the file contains the reference to master

ref: refs/heads/master

If we were on a branch we could expect the contents to be something like this


ref: refs/heads/production_fix

where “production_fix” is the name of the branch.

description – As the name suggests, this files contains the description of the repository we have created. Since we have not entered any information in this file we see the following contents in the file.

Unnamed repository; edit this file 'description' to name the repository.

Some of the GIT UI tools use this file to show the description of the repository to the user.
config – This file contains the configurations specific to repository. We can change our username or email which will be used in the commit, by adding entry in this file. Current snapshot of our file looks like this.


[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true

branches a deprecated way to store the URL to git fetch, pull or push is to create a file in
branches/<name>, and use that name to the command instead of repository parameter.

objects – We can call this as the database of the git repository. Git mainly stores all its contents in three type of objects i.e. commit, tree, and blob. More details about these objects will be discussed in the next article.

With continued use of git for the project, there are a number of files are folder that are added by git in this .git directory. However, the folders and files mentioned above are enough to give you good understanding of GIT repository.

GIT tutorials

cowboybkit — Fri, 03 Aug 2012 08:28:51 +0000

Tutorial 1: Switch changed code to new branch If you make some change on master branch and want to t

What the Git?

jacobmoe — Mon, 23 Jul 2012 18:39:10 +0000

Trying to get started with Ruby on Rails – the popular web development language – I found this helpful but slightly out-of-date install guide for getting setup on Mac OS X. Follow the instructions, but get the software from the respective websites rather than using the download links provided.

One of the steps is installing something called “Git.” As it turns out, Git is an incredibly useful version control system, but it took some searching before I found a clear explanation for what exactly that means. Most explanations went something like: “Git is a lightweight version control system with an emphasis on speed.” But what is a version control system and how is it used? Luckily, I found these easy to follow screencasts with the basics to understand and get started using Git:

Deployment through Capistrano

fan0o — Wed, 04 Jul 2012 07:25:39 +0000

Install gem gem install capistrano Generate a key ssh-keygen Copy the key without white spaces or a

Git Cheat sheet

fan0o — Tue, 26 Jun 2012 13:30:57 +0000

Setup ----- git clone clone the repository specified by ; this is similar t

Git Primer

hctahkram — Mon, 25 Jun 2012 18:57:53 +0000

Quick reference guide for useful Git commands

Based off the Git Book

I wrote this when I was told to learn Git for work.

Index

1. Git Basics

2. States of Files

3. Getting and Creating Projects

Initializing Git Repository
Cloning an Existing Repository

4. Basic Snapshotting

Checking Status of your files
Tracking new files
Ignoring Files
Viewing Changes
Committing your Changes
Removing Files
Moving Files

5. Viewing the Commit History

Limiting Log Output
Using a GUI

6. Undoing Things

Changing Your Last Commit
Unstaging a File
Unmodifying a Modified File

7. Working with Remotes

Showing your Remotes
Adding Remote Repositories
Fetching and Pulling from your Remotes
Pushing to your Remotes
Inspecting a Remote
Removing and Renaming Remotes

8. Tagging

Viewing Tags
Viewing Tag Data
Creating Annotated Tags
Signed Tags
Lightweight Tags
Verifying Tags
Tagging Older Commits
Pushing Tags to Remote

9. Basic Branching and Merging

Create a Branch
Merging Branches
Deleting Branches
Branch Management

10. Branching Workflow

11. Remote Branches

Pushing
Tracking Branches
Deleting Remote Branches

12. Rebasing

The Basic Rebase
More Complex Rebasing
Drawbacks of Rebasing

1. Git Basics

Git takes snapshots of your commits, rather than saving differences. Acts more like a mini filesystem.
Nearly every opertaion is local. You don’t need to be online to make commits.
Git uses checksums for lots of things, including identifying commits.
Git generally only adds data. It is hard to get the system to do anything that is not undoable or make it erase data in any way.

2. States of Files

Modify the Files -> Stage the Files -> Commit The Files
Unstaged (Unmodified) -> Unstaged (Modified) -> Staged Files ( git add) -> Committed ( git commit)

3. Getting and Creating Projects

Initializing Git Repository

To start tracking an project. This creates all the necessary repository files. (Nothing will be tracked yet!)

git init

Cloning an Existing Repository

Different from checkout. Cloning copies almost all data on a repository. Includes all previous versions of every file in the project.

git clone [url]

4. Basic Snapshotting

Checking Status of your files

git status

Tracking new files

git add <file>

Ignoring Files

This is generally for ignoring automatically generated files.

You can do this by creating/editing the .gitignore file.

Rules for patterns you can put into .gitignore:

Blank lines or lines starting with # are ignored.
Standard glob patterns work.
- * – matches zero or more characters
- [abc] – matches any character inside the brackets (a,b,c in this case)
- ? – matches a single character
- [0-9] – matches any characters in range within bracket.
You can end patterns with a forward slash ( /) to specify a directory.
You can negate a pattern by starting it with an exclamation point ( !).

Viewing changes

To see changes that are not yet staged.

git diff

–cached or –staged - Shows what you’ve staged that will go into the next commit.

Commiting your changes

git commit

-a - makes Git automatically stages every file that is tracked. (Otherwise you need to git add each file),

-v - shows diff in changelog so you can see exactly what you did (is removed when the commit is created).

-m - inline commit | ex. git commit -m “Story 182: Destroyed all the bug monsters”

Removing Files

git rm <file>

-f - force removal, used if file was modified and added to index already

–cached - keep file in working tree, but remove git tracking.

Git does its own filename expansion in addition to your shell, see example below.

ex: git rm log/\*.log - backslash is necessary (removes all files in log directory with .log extension)

Moving Files

Git doesn’t explicitly track file movement. If you rename a file in Git, it won’t know.

git mv file_from file_to

OR you can remove old file from tracking and add new one. ( git rm, git add)

5. Viewing the Commit History

git log

-p - shows the diff introduced in each commit

-<n> - limits the output to the last n entries if diffed

–stat - abbreviated stats

–shortstat - display only changed/insertions/deletions from –stat

–name-only - list of files modified

–name-status - shows the list of files affected with added/modified/deleted information

–abbrev-commit - abbreviates checksum

–relative-date - displays date relative to today (“2 weeks ago”)

–pretty - allows formatting of log output

=oneline - prints each commit on single line

=short

=full

=fuller

–graph - ASCII graph showing branch and merge history

Limiting Log Output

git log

–since, –after - Limit the commits made after date ( ex. git log –since=2.weeks or –since=”2008-10-01″)

–until, –before - Limits the commits to before date

–author - only shows commits which author entry matches string

–comitter - only shows commits which committer entry matches string

–grep - search for keywords in commit messages

–all-match - specifies that all log limiters must be true (ex. when searching author and grep, otherwise it will match all commits with either.)

–<dir>, –<file> - always the last option, only shows commits relative to a directory or file.

–no-merges - don’t show merges

Using a GUI to Visualize History

gitk

Opens GUI interface for viewing git log.

6. Undoing Things

Changing your last Commit

git commit –amend

Takes your staging area and uses it for the commit.

Unstaging a file

git reset HEAD <file>

Unstages a modified file in git.

Unmodifying a Modified File

git checkout — <file>

Reverts any changes on a specific file.

7. Working with Remotes

Showing your Remotes

git remote

*-v* - shows URLs and lists all remotes

Adding Remote Repositories

Add a remote repository with your custom shortname

git remote add [shortname] [url]

Fetching and pulling from your Remotes

Pull all data from remote project that you don’t have. Doesn’t automatically merge.

git fetch [remote-name]

Pull all data from remote project that you don’t have. Automatically try to merge.

git pull

Pushing to Your Remotes

Push your changes to the remote repository, must have write access.

git push [remote-name] [branch-name]

Inspecting a Remote

View more information about a remote repository.

git remote show [remote-name]

Removing and Renaming Remotes

Change remote’s shortname

git remote rename <old shortname> <new shortname>

Remove a reference to remote repository

git remote rm <shortname>

8. Tagging

Viewing Tags

git tag

Viewing Tag Data

git show <tag name>

Creating Annotated Tags

This is the most common type of commit. It adds a message to describe the tag,

git tag -a <name of tag> -m <tag message>

Signed Tags

git tag -s <name of tag> -m <tag message>

Lightweight Tags

Only contains the commit checksum.

git tag <tagname>

Verifying Tags

git tag -v [tag name]

Tagging Older Commits

To tag old commits, simply add the commit checksum of the paticular commit at the end of the command.

git tag -a <tag name> <commit checksum>

Pushing Tags to Remote

Git does not transfer tags by default to the remote repository.

git push <repository shortname> <tagname>

–tags - push all tags to remote server

9. Basic Branching and Merging

For more detailed info:

http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging

Create a Branch

Creates a branch off the current tree.

git branch <branch name>

This does not switch to the branch however, you still need to perform a checkout to do that.

git checkout -b <branch name>

This will create a new branch and switch to it.

Merging Branches

Merges branch specified with the branch you are currently on.

git merge <branch to merge>

Deleting Branches

git branch -d <branch name>

Branch Management

git branch

-v - show last commit on each branch

–merged - See what branches have already merged into the branch you are on.

–no-merged - Opposite of –merged

10. Branching Workflow

To learn more about using branches in your workflow:

http://git-scm.com/book/en/Git-Branching-Branching-Workflows

11. Remote Branches

They’re local branches that you can’t move; moved automatically whenever you do any network communication. They act as bookmarks to remind you where the branches on your remote repositories were the last time you connected to them.Simple pointers.

Here is a the detailed explanation with diagrams and examples:

http://git-scm.com/book/en/Git-Branching-Remote-Branches

Pushing

Must have write access.

This isn’t done automatically.

To push up a branch git push (remote) (branch)

Can also do: git push (remote) (local branch name):(desired remote branch name)

When you do a fetch of new remote branches, you don’t automatically have a local editable copy.

To get a local branch, must check it out.

git checkout -b (desired branch name) (remote)/(branch)

Tracking Branches

These are local branches that have a direct relationship to a remote branch. This is useful for when you type git push/pull, Git will automatically know which server and branch to push/pull from.

git checkout –track origin/serverfix

Deleting Remote Branches

git push (remote) branch)

12. Rebasing

An alternate way to integrate changes from one branch into another, other than merge.

The Basic Rebase

Rather than merging in two branches together. Rebasing simply takes any changes on a branch and “replays” or “patches” it ontop of the other.

This is exactly the same as merge however, your git history will now be linear and cleaner. No longer having branch divergences.

git checkout branch

git rebase master

git checkout master

git merge branch

Basically take the branches changes, apply them onto master, switch to the master, and fast forward.

Now the branch changes are integrated onto the end of the master changes, and the master pointer has moved to accomodate those changes.

More Complex Rebasing

For diagrams and more details: http://git-scm.com/book/en/Git-Branching-Rebasing

If you have multiple branches, you can do more complex rebasing using the –onto option of rebase.

ex: git rebase –onto master server client

What this does is figure out the patches from the common ancestors of the client and server branches, and replay them onto master.(Along with all the client changes).

In this example case, the client has some common ancestry with the server branch. This is useful if you want to integrate the client changes, without integrating the server changes, while still keeping the common changes that are necessary for the client branch to be implemented. See the link for diagrams.

Drawbacks of Rebasing

DO NOT REBASE COMMITS THAT YOU HAVE PUSHED TO A PUBLIC REPOSITORY.

Rebasing changes the commit hashes, making it look like commits that have already have been committed look new. Causing everyone to have to remerge their old work in.

Use rebasing as a way to clean up and work with commits BEFORE you push them.

Installing Git on Mac OS X

VandadNP — Sun, 24 Jun 2012 15:59:49 +0000

If you want to install Git on your OS X Lion, whether you have Xcode or not, you can head to: http:/

GIT: How to add and remove tags

Aqua23 — Fri, 22 Jun 2012 01:00:22 +0000

To add tags:

If your tag is named v1.1 :

- git tag -a v1.1 -m “Version 1.1″

- git push –tags

To remove tags:

If your tag is named v1.1

- git tag -d v1.1

This will remove from remote repository:

- git push origin :refs/tags/v1.1

Git: How to remove a submodule

Aqua23 — Tue, 05 Jun 2012 22:08:37 +0000

1. Delete the relevant section from the .gitmodules file.

For eg. I want to delete “TestModule” Submodule:

- Go to root directory of git repository

- Run nano .gitmodules

- Delete submodule,path and url section pertaining to “TestModule” submodule

[submodule "TestProj/Classes/TestModule"]
path = TestProj/Classes/TestModule
url = https://github.com/hrastogi/TestModule.git

2. Delete the relevant section from .git/config.

For eg.

- Go to root directory of git repository

- Run nano .git/config

- Delete submodule and url section pertaining to “TestModule” submodule

[submodule "TestProj/Classes/TestModule"]
url = https://github.com/hrastogi/TestModule.git

3. Run git rm --cached path_to_submodule (no trailing slash).

For eg:

- rm –cached TestProj/Classes/TestModule

4. Commit and delete the now untracked submodule files i.e delete “TestModule” directory locally.

Refer : Delete Submodule

Changing URL for Remote

admin — Mon, 07 May 2012 01:26:11 +0000

I changed the hosting of my repo from Github to Bitbucket. I like Bitbucket because not only does it house the code and history, but also it ties in with a bug tracker that allows for tracking (and assigning) of bugs, but also collaboration with developers.

To remap my remote repo, I did this:

git remote set-url [example] [git://github.com/user/test.git]

where:

[example] = repo name

[git://github.com/user/test.git] = new repo url

Git Commands

admin — Sun, 06 May 2012 19:19:02 +0000

Here are the git commands I use most often (I use git GUI so I don’t usually type the commands git add, git commit, & git push to move files):

git branch – tells you what branch you are currently in
git checkout – switch branches
git merge – bring in the code from the named branch, into the current branch
git pull [repository] – pull my files
git push [repository] – push my files
git stash – store local changes (usually when there is a merge conflict)
git stash apply (retrieve the stashed local changes)

for me:
[repository] = origin
= master and dev

Using Git with Github on Windows

Sina Iravanian — Sat, 05 May 2012 04:20:32 +0000

If you’re new to Git and don’t know how to install Git on Windows, read my earlier post: How to Setup Git for Windows

In an earlier post, I described the preliminary steps required to work with git on CodePlex. However using git with Github requires more initial steps.

Generating SSH Keys. Before proceeding to Git operations we need to create SSH public and private keys, and register the public key on the Github site. In order to generate the keys we can use PuTTY Key Generator, which is already bundled with TortoiseGit fortunately. This program is called “Puttygen” and can be found in start-menu under TortoiseGit:

After running Puttygen you need to press “Generate“, and make some crazy mouse movements in the spotted area to provide some random data for the program (wow, what a brilliant idea). When finished you will have the public key generated. It is recommended that you provide a passphrase so that you would have a more secure private key. After that save your public and private keys using the 2 save buttons near the bottom of the window. But these are not all that you need to save! The public key format that Github and some other applications require you to provide is not the one that this program has saved for you. The topmost field which is labeled “Public key for passing into OpenSSH authorized_keys file” is the one that Github needs. It should be in one line (i.e., with no line-breaks), therefore we would refer to it later as the one-line-public-key. Please save the contents of this field and the next “key fingerprint” field somewhere for future references.

Registering SSH Keys in Github. Browse to Github, and go to your Account Seetings, and select SSH Keys therein. Press the Add SSH key button on the right. Provide a name for the key (I chose TortoiseGit), and paste the one-line-public-key in the Key field. Press Add Key. You may be prompted for your Github account password next. When finished, Github adds this key to its list of keys and provides a fingerprint. Make sure this fingerprint matches the key fingerprint that Puttygen created for you.

Creating a Repository in Github. Browse to the Github page and press the “Create a New Repo” button at the top of the page.

In the new form that appears, enter desired values for your project’s name and description. Currently there’s an option to add a README file or an appropriate .gitignore file to the repository. While making use of these options are recommended, in this tutorial I intend to start from a completely empty repository; therefore I unchecked those options. When finished press the “Create repository” button. With these steps I created a project called “PdfRenamer“.

Setting up TortoiseGit for the new project. After creating the repository, Github introduces some helpful basic commands to start working with the repository. We don’t intend to use the command-line, however this page contains useful information such as user-name and email with which Github recognizes you, and the git repository address, as highlighted below:

We need to do the following steps next:

Right click somewhere in the Windows explorer window, and from the context-menu go to: TortoiseGit > Settings >> Git branch; and fill the user-name and email fields with the ones suggested by Github, and press OK.
Create a folder preferably with the same name as your project (in my case PdfRenamer), and browse into it with Windows explorer.
Right click somewhere in the folder and from the context menu select “Git Create repository here…“. A window pops-up. Make sure that “Make it Bare” is not checked; and press OK.
Right click somewhere in the folder and from the context menu go to: TortoiseGit > Settings >> Git branch >> Remote sub-branch. In the “Remote” field enter “origin“, in the URL field enter the git repository address which was highlighted above and is in the form of git@github.com:[username]/[projectname].git; and finally in front of “putty key” provide the address to the SSH private key which we saved earlier in this tutorial, and has the .ppk extension. When finished press the “Add New/Save” button. After that origin should be added to the list of Remotes.

Add files to the project structure. With git, adding a file to a project structure and having it reflected in the remote repository requires 3 operations: add, commit, and push. The first 2 operations are required for adding the file to the local repository, and the third one reflects the changes to the remote repository. This last operation can be postponed to a later time when you want to push a bundle of changes all at once.

To start, create a Readme.txt file in the root folder. Right click on the newly added file, from the context menu select: TortoiseGit > add; check the files to be added, and press OK. This was the first operation: add. In the new window press “commit …“, provide a meaningful commit message in the new window, and press OK when finished. This was the second operation: commit which reflects the changes to your local repository, the one in your hard-drive. You can push the changes in the next window if you want, however it’s not a good idea to push every local commit to the remote repository (that’s why we are using a DVCS after all).

Before continuing to the push command, let’s talk about some naming conventions in the Git world. With DVCSs such as git you can have different remote repositories which you may choose from to push your changes to. By convention, the default name for the remote repository is “origin“. In our case origin is the remote repository at the Github server, for which we manually added the link before. On the other hand, each project may have several branches. Conceptually a branch is another copy of the same project where other features are developed and tested. For example imagine that at a certain stage of development you may decide to add a new feature to your project. You may create a new branch called “test”, develop and test the feature there, and finally merge the changes with the code at the main branch. By convention, the main branch is called “master“.

When it comes to push, you need to know which branch of the code you want to push to which remote repository. In our simple case we want to push the master branch to the origin repository. For this purpose, right click somewhere on the Windows explorer that shows the project root folder, and select: TortoiseGit > Push…. Make sure the name of the branches for local and remote repositories and the name of the remote repository are selected correctly. More importantly make sure that the “Autoload Putty Key” check-box is also checked, and press OK. Next, the TortoiseGit will prompt you for the private-key passphrase. Note that this is not your Github account password, this is the passphrase that you chose when creating the private key with Puttygen. After finishing the push operation, check the sources in the project’s Github page to make sure the changes have been reflected there. Note that after the first push, the PuTTY authentication agent (Pageant) get’s run in the background, so that you won’t need to enter the passphrase anytime you want to push to Github.

Updating the local repository with the latest changes made by other team members to the remote repository. Well, there are two solutions. The one that I prefer is using git pull. You can easily find this command in the TortoiseGit’s context menu. The pull command, preserves the history of changes made by different people and makes a final merge afterwards. The other solution is git fetch and rebase. The fetch command only receives the latest changes from the remote repository but does not apply them. The rebase command first applies the remote changes to the repository, then applies your changes. Therefore it always seems that you have made the recent changes, while it may not be true. See this stackoverflow question for a better explanation.

Note: At any stage, if git complains about connecting through a null proxy, then you will have to remove proxy settings from the global .gitconfig file. For more information see tip 7 on my earlier post

You may also want to see my earlier post that describes using git with CodePlex on Windows.

Using Git with CodePlex on Windows

Sina Iravanian — Fri, 04 May 2012 04:58:36 +0000

If you’re new to Git and don’t know how to install Git on Windows, read my earlier post: How to Setup Git for Windows

On 21 March 2012, the CodePlex team announced their support for Git.

Creating a project with Git source control is very easy in CodePlex and is done with a few clicks at no time. Suppose the project name is CodePlexGitTest. In order to make any changes to the project structure you need to clone the project first. This way you will have your own copy of the repository on your hard disk. To do this the path to the git repository is needed. This can be obtained from the Source Code tab of the project’s CodePlex page, by pressing the Git link/button under “Source Control” section on the right pane, as seen below:

In order to clone the project, move to the folder that is going to host the project directory. Right click somewhere in the Windows explorer window and choose Git Clone. In the opened window set the “Url” field to the “Clone URL” value above, leave other options unchanged, and press OK. After prompting for your CodePlex user-name and password, it should now create the folder structure for your empty repository (Note: in case that git complains about connecting through a null proxy, then you will have to remove proxy settings from the global .gitconfig file. For more information see tip 7 on my earlier post).

Now that you have the currently empty project structure at your hard-drive, it’s time to add some files to it. Using git, adding a file to a project structure and having it reflected in the remote repository requires 3 operations: add, commit, and push. The first 2 operations are required for adding the file to the local repository, and the third one reflects the changes to the remote repository. This last operation can be postponed to a later time when you want to push a bundle of changes all at once.

Before continuing to the push command, let’s talk about some naming conventions in the git world. With DVCSs such as git you can have different remote repositories which you may choose from to push your changes to. By convention, the default name for the remote repository is “origin“. In our case origin is the remote repository at the CodePlex server. On the other hand, each project may have several branches. Conceptually a branch is another copy of the same project where other features are developed and tested. For example imagine that at a certain stage of development you may decide to add a new feature to your project. You may create a new branch called “test”, develop and test the feature there, and finally merge the changes with the code at the main branch. By convention, the main branch is called “master“.

How to update the local repository with the latest changes made by other team members to the remote repository? Well, there are two solutions. The one that I prefer is using git pull. You can easily find this command in the TortoiseGit’s context menu. The pull command, preserves the history of changes made by different people and makes a final merge afterwards. The other solution is git fetch and rebase. The fetch command only receives the latest changes from the remote repository but does not apply them. The rebase command first applies the remote changes to the repository, then applies your changes. Therefore it always seems that you have made the recent changes, while it may not be true. See this stackoverflow question for a better explanation.

How to create and delete tags on Github

Panupan Sriautharawong — Thu, 03 May 2012 18:23:36 +0000

Creating a tag:

$ git tag -a [tag] -m "[tag]"
$ git push origin --tags

Deleting a tag:

$ git tag -d [tag]
$ git push origin :tags/[tag]

Setting up a Github project

Henri Siponen — Wed, 02 May 2012 10:32:01 +0000

So I felt like setting up Github repository for awaseroot. Git is a version control system and with Github you can share your git project/repository online. We use Github as a place to share all our awaseroot material. There’s many good tutorials available (for example: http://help.github.com/win-set-up-git/) but here’s the steps I took one by one. Replace awaseroot with whatever you want.

Ubuntu 12.04
Git version 1.7.9.5

The goal is to publish this:

Like this:

First. Create an account to Github:
https://github.com/signup/free

Create a new repository:
https://github.com/new
Repository name: awaseroot
Description: http://awaseroot.wordpress.com
Public
Initialize this repository with a README
-> Create repository

Install git:
sudo apt-get -y install git

Configure git:
git config --global user.name "Firstname Lastname"
git config --global user.email awaseroot@example.com
Use the same email you used when creating the github account.

We need SSH key for the Github:
copy contents of ~/.ssh/id_rsa.pub
Or if you don’t have the key yet, create it with this first:
ssh-keygen

Connect to github to authenticate:
ssh -T git@github.com

Clone the created Github repository:
git clone git@github.com:awaseroot/awaseroot.git cd awaseroot

Add the github repository as a remote git:
git remote add awase git@github.com:awaseroot/awaseroot.git
(You can change awase to whatever you want.)

Create/add content to your project and push it to github:
cp -r ~/puppet/ ~/awaseroot/ git add puppet git commit -m "First Puppet files added" git push awase master

Your new pushed material should be now available in your github.
https://github.com/awaseroot/awaseroot

Becoming a collaborator to an existing github repository

So you have your git already configured, Github account ready with SSH key and now someone adds you as a collaborator. Here’s what to do:

If the repository is for example git@github.com:awaseroot/awaseroot.git
Clone the repository:
git clone git@github.com:awaseroot/awaseroot.git

You should now have the awaseroot directory. Go there:
cd awaseroot/

Add the repository as a remote:
git remote add awase git@github.com:awaseroot/awaseroot.git

Add your files if you have something to add:
cp ~/puppet/manifests/site.pp ~/awaseroot/puppet/manifests/
git add puppet/manifests/site.pp

Commit and push your changes:
git commit -m "site.pp added"
git push awase master

Everyday use

Every time you make changes to your repository you can use these commands to commit changes:
git add my_file # add a file called my_file to git.
git add . # add all modified files to git and remove deleted files.
git commit -m "commit description" # commit changes.
git push awase master # push changes to remote git (github).
(change awase with whatever you defined as a remote)

If someone else has made changes to your git repository, pull the changes with this:
git pull awase master

You’ll get an error message if there’s new changes in your git and you try to commit before pulling
those changes.

Sources
https://github.com

How to setup Git for Windows

Sina Iravanian — Tue, 01 May 2012 15:29:44 +0000

These are some easy steps required to setup Git for Windows:

Download msysGit from: http://code.google.com/p/msysgit.
I prefer to use the portable version. At the time of this writing there’s no difference between 32 bit and 64 bit versions and the filename for the portable version is: PortableGit-1.7.10-preview20120409.7z. Currently it seems that the development of the project has been moved to Github, but the releases are still located in Google Code.
Extract the contents in a proper location. I made them into:
D:\PortableProgs\msysGit
If you intend to use the git command-line for every git operation simply run git-bash.bat in the root folder of msysGit. Yes, this is the old lovely Cygwin command-line.
If you don’t intend to use command-line (like me) install TortoiseGit. It is hosted at Google Code:
http://code.google.com/p/tortoisegit/
Note that it comes with different releases for 32-bit and 64-bit systems. At the time of this writing the latest version is 1.7.8.0. After installing TortoiseGit you may need to restart Windows, or the explorer process, or none.
Right click somewhere on a Windows Explorer window, and from the context menu select: TortoiseGit > Settings. There will be a message-box appearing begging for adjusting the path to msysGit. Click on “Set MSysGit path” button (If you have ever missed this window, or want to change the path to an already existing msysGit, simply go to: TortoiseGit > Settings >> the General branch).
In the field titled as “Git.exe path:” enter the path to the bin folder of the msysGit installation/copy.
You don’t have to, but it is highly recommended that before starting any git operations you set some global settings such as your name, email, and AutoCrlf. To this aim in the Windows explorer’s context menu go to: TortoiseGit > Settings >> the Git branch. Fill in the fields labeled Name and Email with proper values. Then make sure that AutoCrlf check-box is unchecked, so that you don’t touch every file in order to change their line-endings. Read more about this kind of problem here, and see here to know more what AutoCrlf and SafeCrlf options do for you.
[UPDATED on 3 May 2012] When performing some git operations, git may complain that it cannot connect through a null proxy. It may happen for some versions if in git settings the value for proxy is assigned to an empty string. If this is the case for you, simply remove proxy settings in the global .gitconfig file. To do this, right click somewhere in Windows explorer, go to: TortoiseGit > Settings >> The Git Branch >> Edit Global .gitconfig button. From there remove the line that assigns proxy, or the whole “[http]” section if it only contains proxy settings.

git-2 « WordPress.com Tag Feed

Default editor for Git

git reset

List files having conflicts on git

Colorize your git output

Git Internals - branches

Git Internals - .git folder

GIT tutorials

What the Git?

Deployment through Capistrano

Git Cheat sheet

Git Primer

Quick reference guide for useful Git commands

Based off the Git Book

Index

1. Git Basics

2. States of Files

3. Getting and Creating Projects

Initializing Git Repository

Cloning an Existing Repository

4. Basic Snapshotting

Checking Status of your files

Tracking new files

Ignoring Files

Viewing Changes

Committing your Changes

Removing Files

Moving Files

5. Viewing the Commit History

Limiting Log Output

Using a GUI

6. Undoing Things

Changing Your Last Commit

Unstaging a File

Unmodifying a Modified File

7. Working with Remotes

Showing your Remotes

Adding Remote Repositories

Fetching and Pulling from your Remotes

Pushing to your Remotes

Inspecting a Remote

Removing and Renaming Remotes

8. Tagging

Viewing Tags

Viewing Tag Data

Creating Annotated Tags

Signed Tags

Lightweight Tags

Verifying Tags

Tagging Older Commits

Pushing Tags to Remote

9. Basic Branching and Merging

Create a Branch

Merging Branches

Deleting Branches

Branch Management

10. Branching Workflow

11. Remote Branches

Pushing

Tracking Branches

Deleting Remote Branches

12. Rebasing

The Basic Rebase

More Complex Rebasing

Drawbacks of Rebasing

1. Git Basics

Git takes snapshots of your commits, rather than saving differences. Acts more like a mini filesystem.

Nearly every opertaion is local. You don’t need to be online to make commits.

Git uses checksums for lots of things, including identifying commits.

Git generally only adds data. It is hard to get the system to do anything that is not undoable or make it erase data in any way.

2. States of Files

Modify the Files -> Stage the Files -> Commit The Files

Unstaged (Unmodified) -> Unstaged (Modified) -> Staged Files ( git add) -> Committed ( git commit)

3. Getting and Creating Projects

Initializing Git Repository

Cloning an Existing Repository

4. Basic Snapshotting

Checking Status of your files

Tracking new files

Ignoring Files