关于git配合tortoiseGit的基础使用 - 萧冲 - 博客园
一定要自己写出来才能牢记，所以我来写一下 & git确实比svn好用的多了，最起码只有一个文件夹用来标记版本信息比svn所有文件夹下都要放一个文件夹来标记版本信息先进多了，不然你不想要版本管理这些文件的时候，删除起来能类似你（不采用什么特别方法或者工具的话）。 首先安装windows版的git，然后安装tortoiseGit，这些不赘述。 新建一个文件夹，比如为gitbase作为新建一个项目的测试。目前不要有中文，git对路径中的中文支持还不太好，功能好像没什么问题，但是乱码什么的看起来确实不舒服。 1 新建一个项目
图中红框中的选项
一般然后会出现这个对话框，直接OK
出来这个对话框就可以了 2 新建测试文件
新建一个文本文件（测试效果直接），打开文档，在里面输入 版本一 ，然后保存退出 3 提交更改
在文件中点击右键，选择图中红框选项，弹出以下对话框
选中刚才新建的文本文档，在上面的输入框里填写注释，比如填写 版本一，然后 OK，弹出以下对话框
直接 close 就可以了 然后再打开文本文档，增加 版本二 内容，保存退出后，再提交，注释填写 版本二 ，然后下面查看版本记录 4 版本历史记录 点击右键，
上图右边中的show log 选项，
这就是版本记录 5 版本恢复 假设现在到了版本二，我要做一些更改，但是还不确定是否作为正式版本中的更改，那么我就需要先建立一个版本分支（先别管分支是什么，做完这一步就知道什么意思了）
上图中红框中的选项，建立分支
我这里起名为 v3 ，版本三的意思，选择复选框中的 切换至分支，然后ok 此时再点右键，发现菜单变了，下图中的红框部分，提交的时候就会提交到刚才我们建立的分支 v3
现在打开文本文档，添加内容 版本三 ，保存退出，提交。 再来看版本更新历史
里面就出现了v3 和 master 两条版本路线。 现在提出问题，我觉得分支v3版本稳定，可以作为主版本的一部分，也就是说版本三在基于主版本修改后，要把更改合并到主版本中，现在就要做如下操作 6 切换分支
上图红框选项，出现对话框
选择master ，OK
上图中红框中的merge选项，
选择合并来源，选择分支 v3，OK 好了，现在看一下文本文档，里面已经有了 版本三 的内容了。 所以，从现在来看，git的主体思路就是不断的建立分析，可靠以后再合并到主分支里面，从而使得整个版本不断更新。当然相关的功能必不可少，比如版本回溯，就是发现当前版本不够好，返回到之前的某个版本重新来过等等，这些功能也非常重要，但是只要明白了主线，就可以明白为什么有那些相关功能了。git本身就是为使用而开发的，所具有的功能都是现实使用中碰到的最常见的问题。如果你在使用过程中，发现一个情况不知道如何处理，你只要想一下这个情况别人是否会遇到，如果是的话，那这个软件应该有相关的功能或者功能组合来帮你处理问题。学一点Git-20分钟git快速上手 - Blog by Neil
记录生活，分享知识，传播乐趣
您当前位置:
& 学一点Git–20分钟git快速上手
在Git如日中天的今天，不懂git都不好意思跟人说自己是程序猿。你是不是早就跃跃欲试了，只是苦于没有借口（契机）。 好吧，机会就在今天。 给我20分钟，是的，只要20分钟， 让你快速用上git。
我们废话不多说，直接来干货。
我们将会介绍一下几点：
一， 什么是git
二，使用git的一般开发流程
三，快速安装新建项目。holloword。
一，什么是git。
阅读本文的前提是你知道或者用过至少一种源代码管理工具，比如：SVN, CVS 或者TFS等等。 你必须知道什么是源代码管理。如果这些都不满足。请直接跳过本文。
了解陌生事物的最好办法，是和已知事物类比。 —孔子
我们以svn为例。  我们都知道传统的源代码管理都是以服务器为中心的：
每个开发者都直接连在中间服务器上， 本地修改，然后commit到svn服务器上。
这种做法看似完美，但是有致命的缺陷：
1. 开发者不能本地跟踪代码版本。 所有的信息都是在服务器上。  你把本地的代码改了很多，但是又不能提交。通常，本地只能缓存一个版本。对于小项目无所谓， 但是项目一复杂，人员多就麻烦了。 通常你本地的代码都全是红色的。自己都不知道今天修改了什么， 有哪些修改是真正应该提交给svn的。
2. 因为第一点，一旦离开服务器， 程序猿将无法正常工作。 因为本地不能跟踪代码版本。  你的（几乎）任何操作都必须连上服务器。比如， show log， blame，show history等等。
3. 中央服务器压力过大。  因为每个人都必须把代码提交到服务器，并且做daily build。
4. 对于大型项目， svn几乎不可用。 例如linux内核项目， 开发者何止几万？ 都直接提交给svn服务器的话还不乱套了。
5. 对于个人的私人项目而言（或者对于小公司的项目）， 不用版本控制当然不行，但是为了用版本控制而专门假设svn服务器有有点舍不得。
有没有能解决上述几个问题的东东呢？  恩， 答案是肯定的。
Linux内核的作者也遇到了这些问题，于是他决定再一次改变世界， 重写一个可以本地使用的svn。
对， 这就是git。  分布式代码版本管理系统。（说人话 ：就是不用服务器的svn）
我们来看git的结构：
git没有中央服务器。 你装上git软件之后，你就可以指定本地的文件夹进行版本控制了。你可拔掉网线，然后在本地修改， commit，revert（rollback）， branch， restore， show log， blame， history 等等， 全部你之前在svn里面可以用的操作。 简单的说，你就完美了。
你可能意识到一个问题了。   就是天下大乱了。
每个人都自顾自的开发，怎么协作呢？  恩，通常git比svn会多出两个操作， 就是 pull 和push。
我们看一个复杂一点的图：
开发者之间通过 pull和push操作， 把别人的修改拉过来，或者把自己的修改推给别人。
恩，你可能还是觉得有问题，我们生产 环境中， 以谁的代码为最终版本呢？ 
这个问题确实比较棘手，因为，从单纯的技术上将，每个开发者的机器都是对等的。 没有主次之分。
我们还有办法：
技术上不能解决的问题，我们从制度上解决. —- 孟子
从分布式环境中我们模拟出一个中心来：
我们引入Leader这个角色。  他的机器是最终版本。 每个开发者都必须把最终的修改版push给leader。 leader会review然后提交。他就是最终版本。
恩， 我们好像还漏掉一个大问题， 说git，怎么漏掉了github呢。 github是什么。
我们知道，如果每个人都本地修改的话，本地可能不安全，（硬盘坏了，笔记本被偷了。。。。）
我们可能需要一个安全的服务器来存储/备份代码。对于开源的项目，可能是需要一个地方分享你的代码，你不可能24小时开着笔记本，让别人从你这pull代码。
于是， 网上所有的源代码托管网站就冒出来了。 github就是这样的。
看这个图， 我只修改了其中一个地方， 就是把leader的机器换成了。
提供的在线账户。
所以没有git和 github没有必然联系。
这里有几个常用的在线托管地址, 有兴趣自己看看：
1. ，  大名鼎鼎。 免费，只支持开源项目， 不支持私有项目。
，同样大名鼎鼎。 免费， 支持开源项目和私有项目。 免费用户最多5个。项目无限。
3.   git.oschina.net， 国内顶尖托管平台， 我本人正在用的就是这个。  支持开源项目和私有项目。 成员无限， 项目1000个。   使用的是阿里云服务器， 速度极快。  本人推荐5颗星。
二， git开发的一般流程。
上面其实已经涉及了使用git的一般结构。 那么生产环境中， git是如何应用的呢。
本人知道的模型如下：
每个开发者都向自己的项目服务器（leader）提交代码， leader向公司服务器提交。 当然这个leader是可有可无的。如果项目小的话，  开发者可以直接向公司服务器提交。  公司的服务器就是最终版本。  一般公司还会有持续集成CI服务器。  我们可以在公司的源码服务器上设置git的hook。 自动触发CI服务器工作。 这是后话，不多说了。
三，  前面的概念弄清楚之后， 上手就容易多了。 我们helloword。
1.   这是git的官网：  去下载windows客户端。
     如果是linux的话， sudo apt-get install gitcore
2.  注意， 官网的客户端都是命令行的。 命令行是高阶用法。不在这里说了。 我们下个gui。
我用的是TortoiseGit。    ， 大家恐怕都熟悉svn时代的乌龟爬。上手快。 我们下面的操作都是gui上的。
安装过程不说了。 一路next。 我们跳过。 直接到最后。假设你现在已经安装完成了。
比如我已经有一个工程， helloworld：
这是工程文件的内部结构：
现在我们想让helloworld用上git怎么做呢， 在工程根目录下，点击鼠标右键。
选择 Create repository。
这个选项不要勾上。 稍后我们会解释什么是 Bare。
然后就完成了。
里面多出了一个 .git目录。 当前的目录（及其所有子目录）已经在git的监视之中了。 但是当前的代码还没有添加到git的跟踪数据库中。  简单的说，git还没有储存任何版本信息。 我们需要进行第一次提交：
git默认你本地会有一个主分支master。
我们写一些注释， 并且勾上想要添加到git的文件。 （如果有子目录的话， 它都会显示在这里。）
提交完成， close。 这个push按钮，稍后再说。
好了，这个时候我们在回到文件夹，看看有什么变化：
现在这些文件就添加进git了。
剩下的你就可以为所欲为了。 想svn一样，自己试试几个命令吧： 修改， difference， commit， revert，
到这你已经入门了。 
最后我们来介绍两个重要的概念。
1. “git目录”,   就是指上图中，项目根目录下生成的 “.git” 文件夹。  用过svn的同学都知道， svn有‘.svn’文件夹。  他们的作用差不多。 这里保存了git的本地数据库资料。就是所有的版本信息。   跟svn不一样的地方就是，git中，只有根目录下有这个目录， 所有的子目录下都没有， 也就是每个工程只有一个.git目录。
2.  “git工作目录”, 其实就是你的工程目录， 比如上图中的工程跟目录：H:\mycode\helloworld\  。  问什么有这个工作目录呢。 就是你工作在这个目录下， 你可以修改编辑里面的文件，最后把修改提交给git目录。  这个共组目录还有一个神奇的地方就是，  你可以创建不同的branch（你默认工作在master下）， 当你切换不同的branch时， 你的工作目录（工程目录）里的所有文件都会变成当前branch对应的文件。 这个不展开了。
最后再解释上面留下的两个问题：
1. “Bare”  创建Bare的意思是： 你只想要git的数据库（即上图中的 “.git”文件夹。）， 而不想要当前的文件。 这通常用在公司的中央服务器上。 它不需要当前项目的实际代码，只需要保留git数据库信息就行了。
2. 在commit之后的对话框中的 push的意思。   正如之前介绍的。 push的意识是把你的修改push给别人（或者给公共服务器）。  commit的意思只是提交到本地的 .git 数据库。 并没有更新别别人。  所有提交完之后， 乌龟很贴心的给我们一个push按钮。 通过它你可以快速把刚刚的修改push给别人，或者给服务器。 
总结， 这不是一本完全的git手册，但至少能让你消除git恐惧症，快速入手。
这里是gitbook的中文版：   他是真正的大而全。 为什么最后才说她呢？ 因为它就像是一本 牛津大辞典， 全面，权威。  但是对于幼儿园小朋友学英语，就不能一上来就背它吧。  先跟着别人说，上手要紧。   之后有什么不会的，再去查字典。
好了。 就到这。 欢迎大家访问我的个人独立博客：   欢迎大家多多交流。
后面有时间的话，还想给大家分享一下我对几大源码托管服务器的经验。 希望大家顶啊。。。。
From , post
原文来自 , post
转载请注明出处。本站保留一切权力| Released TortoiseGit 1.8.16.0
| Public repository for website online. Feel free to .
| New website put online. Still -)
| Moved from GoogleCode to GitLab
| Released on
| Released on
Here you find the TortoiseGit installer and language packs.
Contribute
TortoiseGit is open source and needs your help!Get involved!
Manuals, FAQ, bug reporting, mailing list, and more&TortoiseGit vs Git Extensions - Stack Overflow
to customize your list.
Stack Overflow is a community of 4.7 million programmers, just like you, helping each other.
J it only takes a minute:
Join the Stack Overflow community to:
Ask programming questions
Answer and help your peers
Get recognized for your expertise
What are the benefits and disadvantage of using either Git Extensions or TortoiseGit on a Windows Based OS?
21.5k58208332
I don't know GitExtensions, but I can share my experience with TortoiseGit (alluded to by marc_s's comment):
Excellent integration with Windows (it's a shell extension)
Nearly the same UI as TortoiseSVN (if you already used TortoiseSVN, you know what to expect).
You will have a hard time understanding how to use git.
The problem with TortoiseGit is that people who worked with TortoiseSVN will think everything will (or should) work exactly like in SVN... and end up never really understanding how to work with git. As a personal experience, the company I work migrated from SVN to git after 2 years, and every single developer that used TortoiseGit ended up not really knowing what they are doing and sometimes screwing up their local repositories. In the end, they dropped TortoiseGit and spend time learning git "the hard way" (shell, msysGit on Windows) and everyone has been happy since then.
Conclusion: Just use msysGit directly and properly learn git. You will avoid many headaches in the future.
My company tried both and quickly dropped Tortoise Git. It crashed much more often. The coders claim that Tortoise Git is not capable enough but I did not check that myself. But I did see lots of The crashes myself.
The Coders prefer git bash, the others use but hate git Extensions. Although even some of them additionally open up git bash. Git bash is unavoidable to see the progress counters.
Git Extensions has no option to show progress counters during a pull. So with Git Extensions only, you sit in front of an enigmatic non-progress bar, not knowing what happens and whether something failed. The worst is a missing or incorrect password: Git Extensions just lets you wait forever, showing the same glowing bar as if it was doing something time-consuming. Another horror of Git Extensions is the frequent abort with "out of memory", when versioning many big files and pulling with rebase. After such an abort, non-coding users are always overwhelmed with problems. Many files that they did not change show up as changed and the lock file prevents them from dealing with the problem, etc..
In my opinion both GUI tools are immature.
You want Git Extensions for one important reason - it shows you the graphical view of the commit log (see below). Without that graphical view I don't think most folks new to git will ever get what is going on with branches, commits, rebasing, cherry picking, etc (I know I didn't).
You are going to do want to do some of your work on the command line also, it's your best bet to practically use git since all the help you get will be command line based.
All that said, you can use Tortoise Git also (assuming it works) since they all call the same command line executables and act on the same git repository.
Most IDEs have git support also, JetBrains IDEA does a great job of adding change lists and other functionality on top of it.
I don't have much experience with TortoiseGit, but I installed, and am currently using GitExtensions v2.21.
The biggest advantages with using GitExtensions:
visual gitk-like graphical display of codelines and branches, with all essential info available in tabs, eliminating any need to work with the unfriendly SHA's.
ability to install as Administrator and all other users on the same PC can use it just like any regular user.
built-in shell integration with Windows Explorer
out of the box integration with Visual Studio (Windows Eclipse users only need msysgit, as they have their own GUI to replace the need for GitExtensions)
easy to use installer that comes pre-packaged with all necessary and pre-requisite functionality to start out of the box (SSH Client, KDiff, msysgit).
integration with GitHub (Fork,clone, pull are all streamlined)
Disadvantages:
documentation does not keep up with the new features constantly being added.
For example, I still don't know how to use the scripting features.
Lest we forget that it is a completely free program, and offered to us as an option with no strings attached, I don't see the rationale for such high expectations placed upon it, as if we were paid clients?
I have seen some of the aborts and freezing that the previous user mentioned, but I believe the majority of that has been fixed in v2.24.
Alot of the aborts and failed actions are really not the fault of GitExtensions, but more a symptom of a systemic problem outside of GitExtensions (eg. misconfigured SSH setup, file permissions issues on the server hosting the remote repo, etc).
For example, there was one time when I did a simple push which caused fail and abort.
It turns out that the remote I was trying to push to was on a very long pathname which was causing problems for the Mac server that hosted the repo.
Anyways, that said however, my experience with GitExtensions has been fairly positive.
I find the benefits outlined above have made it worthwhile to put up with the occasional aborts and freezes until the bugs are fixed.
I can't speak to Git Extensions as I've never used it. Had some problems with pure GIT. Couldn't integrate GVIM, for instance. Tortoise Git has an integrated editor and diff tool (which is amazing), so that's a very nice convenience. I loved the branch diagrams in the Scott Chacon book and was hoping TGit would have a similar diagram. They do have a tool for showing branches but it's not as nice as the one in the book.
One thing to bear in mind is that since TGit is just a shell on top of GIT, there's no harm in mixing the two methods. I use TGit for most everything, but dip into GIT for commands that are awkward or that I simply don't understand well in TGit. But even if you plan to use TGit, it's still important, as mentioned above, to understand the basics of GIT first. I'd read through the first, say, three chapters in the Chacon book (available for free online at
or by purchase at Amazon). If you're like me you may want to read them several times over to let the paradigm sink in. It's not all that complicated, but it is very different from previous VCS's.
TGit never crashed on me, as it has for some of the other reviewers, but then my repo's have been small. It did eat my commit comments on more than one occasion, which could have been user error. Since you can go back and re-edit comments this was just an annoyance and worth the convenience of having a GUI, with windows that show a great deal of info at a glance.
Just to counter some of remarks above:
With the correct expectation, TortoiseGit provides an excellent gui for working with git on Windows. It is not a replacement for TortoiseSvn, but an improved gui over what one can achieve using gitk + git-gui (which can be considered part of core git functionality and accessible in msysgit). The only bad thing I see is how you would not need to remember all the exact commands for checkout/rebase/merge etc, since it is possible to do all that very conveniently through the gui (which is the whole point). The putty/ssh problems have more to do with the inferior support for ssh on Windows, and are not unique to TortoiseGit.
4,54931939
I use GitExtensions.
I haven't used TortoiseGit but one of our other developers loves it and refuses to use GitExtensions.
His reasoning is 1) It' 2) It has great Windows Explorer integration.
Using GitExtensions I tend to use the Windows Explorer integration for three things only:
1) To create a new local repository (context menu item Git Init Here, which is actually a Git for W GitExtensions sits on top of Git for Windows);
2) To open the Git Extensions GUI (the browse window);
3) To clone a remote repository down to a local repository (context menu item Git Extensions > Clone).
For pretty much everything else I just have the GitExtensions GUI up and work from there.
The developers of GitExtensions claim that almost any command can be executed from the GUI.
This is not quite true but I find I only need to drop into the command line interface about once or twice a month for complex tasks.
In some cases the GUI makes complex tasks simple by hiding the complexity of the underlying Git commands.
This sometimes involves combining several Git commands into a single action.
eg Creating submodules where the GUI combines adding a submodule, initializing it and updating it into a single action.
In another case, the GUI simplifies a task by providing a command which Git lacks - removing a submodule (in Git you have to manually edit the various files such as .gitmodules and .git/config to remove a submodule).
I'd be interested to know if TortoiseGit simplifies complex tasks in a similar way.
GitExtensions also has fairly basic Visual Studio integration.
Don't know if TortoiseGit does.
There is a separate Git Source Control Provider for Visual Studio 2008 and 2010 which provides much more extensive Visual Studio integration.
However, having installed the Git Source Control Provider I find I never use it.
The only GitExtensions integration I use from Visual Studio is on the toolbar, to open the GitExtensions GUI with the appropriate repository.
I'll work with Visual Studio on one monitor and GitExtensions open in the other.
From at least version 2.32 GitExtensions shows the number of uncommitted files in its toolbar.
I previously used 2.24 which didn't have this feature and it's very handy.
Gives instant feedback on whether there are any uncommitted changes or not.
4,51132742
For fast and easy compilation, customization, and building extensions,
GitExtensions is better (C#) than TortoiseGit (Visual C++ MFC)
For portability,
GitExtensions is better (.NET on Windows / mono on Linux/Mac) than TortoiseGit (Win32/64 only)
To use icon overlay in Explorer, use TortoiseGit
For performance of some features,
TortoiseGit is better because it calls static / dynamic library to retrieve the result from the repository, while GitExtensions only invokes git.exe command line which has larger overhead.
To migrate from TortoiseSVN,
TortoiseGit will be more familiar with than GitExtensions
9,17342851
At this point, Tortoise Git DOES NOT WORK at all, and the issue on the google code site has not received attention in a month:
The box 'Load Putty Key' from the popup on Tortoise Git's first usage to clone a site (and start developing) is grayed out. So no private key is found, and the error message is 'connection dropped' SUCCESSFUL!!!!
Git Bash works perfectly, albeit console based. And if everyone above talks about not understanding the Git concept when using Tortoise Git, I'd just stay away from it based on that, even not taking into account the last 3 hours I spent trying to get Tortoise Git working for a developer. He's going to have to learn console Git, or go down the road.
I got it working in 15 minutes, and I'm just a hacker trying -)
PS, Eclipse has all three major Version Control repository 'connectors' available and is a very good editor.
Your Answer
Sign up or
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Post as a guest
By posting your answer, you agree to the
Not the answer you're looking for?
Browse other questions tagged
Stack Overflow works best with JavaScript enabled}