Showing posts with label git. Show all posts
Showing posts with label git. Show all posts

2010-10-12

An Illustrated Guide to Git on Windows

http://nathanj.github.com/gitguide/tour.html

About

This document is designed to show that using git on Windows is not a difficult process. In this guide, I will create a repository, make several commits, create a branch, merge a branch, search the commit history, push to a remote server, and pull from a remote server. The majority of this will be done using GUI tools.

Although this guide is targeted for use on Windows, the git gui tool works the same on all platforms. Because of this, git users on other platforms may find useful information here as well.

If you have any comments about this guide, feel free to contact me.

Downloading PuTTY


Although you can use the SSH program that comes with git, I prefer to use the PuTTY Agent to keep track of my SSH keys. If you don't already have them, download putty.exe, plink.exe, pageant.exe, and puttygen.exefrom the PuTTY web site.

Later in this guide, we will use these programs for securely pushing our changes to a remote server.

Installing Git


First, download msysgit. This download is a single executable which installs the entire git system. While going through the installer, you will want to check the options to add Windows Explorer integration when you right click on a folder.



Because we will be using PuTTY as our SSH client, choose Use PLink and fill in the path to the downloadedplink.exe executable.



Continue clicking Next until the installation is complete.

Creating a Repository




To create a repository, first create the folder you want the project to live under. Next, right click on the folder and choose Git GUI Here. Because there is no git repository in this folder yet, you will be presented with the git gui startup dialog.



Choosing Create New Repository brings us to the next dialog.



Fill in the path to your new directory and click Create. You will then be presented with the main interface of git gui, which is what will be shown from now on when you right click on your folder and click Git GUI Here.



Now that the repository has been set up, you will need to tell git who you are so that commit messages will have the correct author. To do this, choose Edit → Options.



In the options dialog, there are two versions of each preference. On the left side of the dialog are options that you want for this repository only, while the right side contains the global options which apply to all repositories. The defaults for these options are sensible so just fill in the user name and email for now. If you have a favorite font, you may want to set it now as well.

Committing


Now that the repository has been created, it is time to create something to commit. For this example, I created a file called main.c with the following content:
#include <stdio.h>

int main(int argc, char **argv)
{
 printf("Hello world!\n");
 return 0;
}

Clicking the Rescan button in the git gui will cause it to search out new, modified, and deleted files in the directory. In the next screenshot, git gui has found our new file (amazing, I know).



To add the file for committing, click the icon to the left of the filename. The file will be moved from theUnstaged Changes pane to the Staged Changes pane. Now we can add a commit message and commit the change with the Commit button.



Saying hello to the world is all well and good, but I would like my program to be more personal. Let's have it say hello to the user. Here's my code for that:
#include <stdio.h>
#include <string.h>

int main(int argc, char **argv)
{
 char name[255];

 printf("Enter your name: ");
 fgets(name, 255, stdin);
 printf("length = %d\n", strlen(name)); /* debug line */
 name[strlen(name)-1] = ''; /* remove the newline at the end */

 printf("Hello %s!\n", name);
 return 0;
}

I had some trouble figuring out why a newline was printed after the user's name, so I added a debugging line to help me track it down. I would like to commit this patch without the debug line, but I want to keep the line in my working copy to continue debugging. With git gui, this is no problem. First, click Rescan to scan for the modified file. Next, click the icon to the left of the filename to stage all modifications for commit. Then, right click on the debug line and chose Unstage Line From Commit.



Now, the debug line has been unstaged, while the rest of the changes have been staged. From here, it is just a matter of filling in the commit message and clicking Commit.


Branching


Now let's say that we want to start adding new features for our next big version of the program. But, we also want to keep a stable, maintenance version of the program to fix bugs on. To do this, we will create a branch for our new development. To create a new branch in git gui, choose Branch → Create. The big feature that I would like to add is to ask the user for their last name, so I am calling this branch lastname. The default options in the Create Branch dialog are all fine, so just enter the name and click Create.



Now that I am on the lastname branch, I can make my new modifications:
#include <stdio.h>
#include <string.h>

int main(int argc, char **argv)
{
 char first[255], last[255];

 printf("Enter your first name: ");
 fgets(first, 255, stdin);
 first[strlen(first)-1] = ''; /* remove the newline at the end */

 printf("Now enter your last name: ");
 gets(last); /* buffer overflow? what's that? */

 printf("Hello %s %s!\n", first, last);
  return 0;
}

And then I can commit the change. Note here that I am committing using a different name. This is to show off something later. Normally you would always use the same name when committing.



Meanwhile, a user informs us that not displaying a comma when directly addressing someone is a serious bug. In order to make this bug fix on our stable branch, we must first switch back to it. This is done usingBranch → Checkout.



Now we can fix our major bug.



If we choose Repository → Visualize All Branch History, we can see how our history is shaping up.


Merging


After days of work, we decide that our lastname branch is stable enough to be merged into the master branch. To perform the merge, use Merge → Local Merge.



Because the two different commits made two different modifications to the same line, a conflict occurs.





This conflict can be resolved using any text editor. After resolving the conflict, stage the changes by clicking the file icon and then commit the merge by clicking the Commit button.


Viewing History


The main.c file is starting to get a bit big, so I decided to move the user prompting portion of the code into its own function. While I was at it, I decided to move the function into a separate file. The repository now contains the files main.c, askname.c, and askname.h.
/* main.c */
#include <stdio.h>

#include "askname.h"

int main(int argc, char **argv)
{
 char first[255], last[255];

 askname(first, last);

 printf("Hello, %s %s!\n", first, last);
  return 0;
}

/* askname.c */
#include <stdio.h>
#include <string.h>

void askname(char *first, char *last)
{
 printf("Enter your first name: ");
 fgets(first, 255, stdin);
 first[strlen(first)-1] = ''; /* remove the newline at the end */

 printf("Now enter your last name: ");
 gets(last); /* buffer overflow? what's that? */
}

/* askname.h */
void askname(char *first, char *last);



The history of the repository can be viewed and searched by choosing Repository → Visualize All Branch History. In the next screenshot, I am trying to find which commit added the last variable by searching for all commits which added or removed the word last. Commits which match the search are bolded, making it quick and easy to spot the desired commit.



A few days later, someone looks through our code and sees that the gets function could cause a buffer overflow. Being the type to point fingers, this person decides to run a git blame to see who last modified this line of code. The problem is that Bob is the one who committed the line, but I was the one who last touched it when I moved the line into a different file. Obviously, I am not to blame (of course). Is git smart enough to figure this out? Yes, it is.

To run a blame, select Repository → Browse master's Files. From the tree that pops up, double click on the file with the line in question which in this case is askname.c. Hovering the mouse over the line in question shows a tooltip message that tells us all we need to know.



Here we can see that the line was last modified by Bob in commit f6c0, and then I moved it to its new location in commit b312.

Pushing to a Remote Server


Before pushing to a remote server, you must first create a SSH public and private key pair. By using SSH, you will be able to securely authenticate to the server that you are who you say you are. Creating the key pair is a simple process. Begin by running the puttygen.exe program downloaded earlier. Next, click theGenerate button to generate the keys. After processing for a few seconds, click the Save private key button to save your new private key. Copy the public key to the clipboard in preparation for the next step. I would recommend not clicking the Save public key button because the saved file is in a non-standard format; trying to use it with other software might be problematic.



Now that the keys are generated, the remote servers need to know about it. If you would like to use githubto host your code, just go to your account page and paste in the public key.



Now github has our public key, but we do not yet have github's. To remedy this, launch putty.exe, connect togithub.com, and click Yes to accept github's public key. You can safely close the login window that opens up after accepting the key.





We need our private key to be loaded up to use with our public key, so launch pageant.exe. This program will create an icon in your system tray. Double clicking on the icon will open up a window into which the private key can be added. Once the private key is added, the agent will sit in the background and provide authentication when needed.



Now that our client and server can authenticate each other, it is time to push! Remote → Push will open up the push dialog. Typing in the commit address for the project and clicking Push will send the changes on their way.





Of course, typing in the remote url would become quite annoying if we had to do it with every push. Instead, git allows us to alias the long urls using remotes. Git gui currently does not have a way to add a remote, so the command line must be used. Right click on the repository folder and choose Git Bash Here. In the prompt, enter the following command:
git remote add github git@github.com:nathanj/example.git

Note: After adding a remote, close and reopen git gui for it to recognize the new remote.

Now the remote github is aliased to the url git@github.com:nathanj/example.git. When viewing the push dialog in git gui, a convenient drop down list of remotes is shown.


Pulling from a Remote Server


Because our code is so useful, dozens of people have downloaded and now use our program. One person in particular, Fred, has decided to fork our project and add his own commits. Now that he's added his code, he would like us to pull those commits from him into our repository. To do this, first create another remote.
git remote add fred ssh://fred@192.168.2.67/home/fred/example

Now we can fetch Fred's changes using Remote → Fetch from → fred.



After the fetch, Fred's commits have now been added to our local repository under the remotes/fred/masterbranch. We can use gitk to visualize the changes that Fred has made.



If we like all of Fred's changes, we could do a normal merge as before. In this case though, I like one of his commits but not the other. To only merge one of his commits, right click on the commit and choose Cherry-pick this commit. The commit will then be merged into the current branch.





We can now push a final time to send Fred's patch to our github tree for everyone to see and use.


Conclusion


In this guide, I have shown how to do many common tasks in git using GUI tools. I hope that this guide has shown that it is not only possible but easy to use git on Windows without having to use the Windows shell for most operations.

If you have any comments about this guide, feel free to contact me.

2010-10-06

Getting Good with Git - eBooks - Tuts+ Marketplace‎

So, you want to learn about Git, the fast version control system? Then you’ve come to the right place!

In this eBook (free for the month of October! Usually $10), I’ll be guiding you through the sometimes-confusing waters of using Git to manage your development projects. The eBook clocks in at a solid 104 pages.

What’s Inside?


Chapter 1: Introduction to Git

  1. What is Git? 7

  2. Why Should I Use a Version Control System? 9

  3. Where did Git Come From? 10

  4. Why Not Use Another Source Code Manager? 10

  5. Summary, 11


Chapter 2: Commands

  1. A Warning, 14

  2. Another Warning, 14

  3. Opening the Command Line, 15

  4. What You’re Looking At, 16

  5. Commands, 17

  6. Advanced Command Line Skills, 24

  7. Summary, 25


Chapter 3: Configuration

  1. Installing Git, 28

  2. Configuring Git, 33

  3. Using Git, 34

  4. Referencing Commits: Git Treeishes, 51

  5. Summary, 52


Chapter 4: Beyond the Basics

  1. Git Add Revisited, 55

  2. Git Commit Revisited, 65

  3. Git Reset, 66

  4. Git Checkout Revisited, 67

  5. Git Diff, 68

  6. Git Stash, 70

  7. Working with Remote Repositories, 71

  8. Git Rebase, 78

  9. Summary, 81


Chapter 5: GitHub

  1. What is GitHub? 84

  2. Signing Up, 84

  3. Tour of the Tools, 87

  4. Creating a GitHub Repository, 92

  5. Forking a Repository, 96

  6. Summary, 101


Appendix A: More Git Resources, 102

Appendix B: Git GUIS , 104

About the Author


I’m a Canadian web developer, the Associate Editor at Nettuts+, and a review on the Tuts+ Marketplace. I prefer JavaScript and Ruby. Soon, I’ll be doing some writing on my personal site; of course, you can follow me on Twitter.

http://marketplace.tutsplus.com/item/getting-good-with-git/128738

2010-08-26

Removing Deleted Files from your Git Working Directory

我们知道git rm file 命令是删除一个文件,文件就进入了暂存区,之后就可以用git commit 来提交删除。但有时候我们从资源管理器中删除了某个文件,再用git st查看状态,git显示文件被删除,但是不在暂存区,这时,用git add .是无法将文件加入暂存区的,因为 git add .只会把当前目录里那些已更改,或者没有被忽略的新文件加入暂存区,对已删除的文件不起作用。那怎么办呢?答案是用 git add -u。它的作用是把工作区内已跟踪文件里更改或的,或者删除了的文件加入暂存区,但对新文件不起作用,它针对的是已跟踪文件。
git add -A = git add -u + git add .
注意A是大写的


Difference of “git add -A” and “git add .”

Removing Deleted Files from your Git Working Directory

2010-08-24

git 笔记

git 的强大就不用说了,目前在windows下使用git,先装 msysgit,再装tortoisegit
msysgit带git命令行 git bash
git init 初始化版本库
git add filename 添加新文件到版本库或者添加修改的文件到提交列表(暂存区)
git add . 同上,所有文件
git commit 提交,回车后会弹出默认文本编辑器以输入 commit message
git commit -a = git add + git commit
git commit -m "fix issue 15252" 直接提供commit message
git diff 比较当前工作目录和暂存区
git diff --cached 比较暂存区和上次提交
git diff HEAD 比较当前工作目录和上次提交

将 Current working directory 记为 (1)
将 Index file 记为 (2)
将 Git repository 记为 (3)
他们之间的提交层次关系是 (1) -> (2) -> (3)
git add完成的是(1) -> (2)
git commit完成的是(2) -> (3)
git commit -a两者的直接结合
从时间上看,可以认为(1)是最新的代码,(2)比较旧,(3)更旧
按时间排序就是 (1) <- (2) <- (3)
git diff得到的是从(2)到(1)的变化
git diff –cached得到的是从(3)到(2)的变化
git diff HEAD得到的是从(3)到(1)的变化
                                                                                                        --Lee.MaRS

git checkout -- filename 丢弃某个文件的更改(如果文件在暂存区,则丢弃添加到暂存区之后的更改,如果不在暂存区,则丢弃上次提交之后的更改)
git reset --hard 丢弃所有更改
git reset -- filename 从待提交列表中移除
git revert HEAD revert上一次的提交,并提交本次操作。
git rm filename 从磁盘删除文件,并添加到暂存区
git rm -r folder 从磁盘删除文件夹(内所有文件),并添加到暂存区,,对于文件, 也可以加上 -r
git rm --cached filename 保留文件,取消对文件的跟踪
git commit --amend 修正上一次提交。比如提交之后发现某个单词写错了,就可以用此命令来  修改上次的 commit message。或者提交后才发现没有把某个修改后的文件add 到暂存区,隐藏没有提交,这是就可以先git add xxx.txt 把文件添加到暂存区,然后运行此命令,把此文件加到上次提交中

2009-12-08

Git Ignore All Files Except .cs etc + Solution

CODE:#ignore everything apart from some kind of file
*
!*/
!*.cs
!*.sql
!*.vb

2009-10-27

git 小结

官方网站 http://git-scm.com/
教程:

官方 教程
Windows 下推荐tortoiseGit ,一个和tortoisesvn一样的图形化客户端
安装:
  1. 下载并安装 msysgit
  2. 下载并安装 tortoiseGit
代码托管:github (推荐)unfuddle