Showing posts with label dvcs. Show all posts
Showing posts with label dvcs. 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-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

2008-07-07

分布式版本控制工具

自己用subversion也得有10几个月的时间了,不但自己用的挺顺手,还推荐给了team,效果显著。最近1.5也发布了,增加了不少新功能,我个人用到的是TSVN的缓存日志功能和changeset功能,特别是tsvn默认提供的ignore-on-commit changeset,给我提供了很大的便利。把不想或不能(例如与个人设置相关的文件)提交,这时

再说一下svn的不足之处,当然这是我喜新厌旧的结果
1)要将一个工程纳入版本控制,必须首先在A出创建版本库,保持版本历史,然后在浅出到B处,然后再在B处(工作)添加要纳入版本控制的文件,或者是创建版本库之后从C处导入要进行版本控制的所有文件,在签出到D处(工作目录)进行开发。但我的情况是,整个项目组用另外一个版本控制工具,工作目录是不可变的(也就是我在同一个目录下同时使用两个版本控制工具,可以想象,这是一件多么痛苦的事情-_-|||),所以我必须把当前工作目录导入到svn,再删除当前目录,再在原地从svn签出文件。
2)工作目录中,每一级目录里都有一个.svn文件夹,很是碍眼。
3) 集中的版本库,一旦版本库服务器关机,所有人将无法提交。
前一阵子研究了一下分布式的版本控制(distributed version control system, DVCS)。所谓分布式,就是所有人都有一个完整的版本库,提交的话只是提交到本地的版本库,这样,基本不需要网络连接,速度也很快。网络连接操作只是clone,push,pull操作。clone,从别处获得一个完整的版本库,pull获得他人的更改,push 把本地更改推送给其他人或者一个“中央”版本库。
我所了解到的dvcs主要有 Bazaar,Mercurial,Git,Darcs
Bazaar,ubuntu 背后的公司 canonical支持的项目,较活跃,目前版本1.5,tortoisebzr貌似好久没有更新了,不过我用cmd的时候中文有时候乱码,再者bzr使用插件的形式扩充其功能,感觉不够简洁(那Firefox呢?你不是装了一堆插件?囧)。不过我喜欢bzr的whoami的设置用户名,还有,有ignore 命令来直接忽略文件,mercuiral 必须使用.ignore文件。
mercurial,又名hg(汞的化学符号)目前版本1.01,tortoisehg也相当不错,不过貌似比较慢,也可能是我自己机器的原因。
Git linux 内核开发的版本控制工具,linux大神Linus Torvalds 所写,主要应用于linux平台,windows下下也有移植版本,据说性能一般
这里有一篇文章论述各个vcs和dvcs 的优缺点:Choosing a Distributed Version Control System
这里有一篇通俗易懂的介绍:Intro to Distributed Version Control (Illustrated)