如何把不同员工开发的java项目模块整合到一起？用什么工具_百度知道
如何把不同员工开发的java项目模块整合到一起？用什么工具
本来只有我自己开发 一个java项目，现在人多了，需要把每个人开发的代码整合到一起 用什么工具 ？
我有更好的答案
ant可以解决;ant可以完成对于不同个project集成到一个大的project的任务；如果你是单一project的不同模块，可以用git来管理你们团队的代码；git也有很多可视化软件例如sourcetree等；希望对您有帮助；个人感觉git要比svn管理项目好一些；
采纳率：57%
不过你们的底层代码必须相同啊 要是每个人做自己的然后想整合是不可能的
本回答被提问者采纳
首先在自己的机子上整合好每个人的代码，保证每个人负责的模块不丢失，项目可以正常运行。 然后再SVN库上提交这个最初的版本，让开发的人员下载使用这个版本，以后有新的代码就可以自己来提交和更新了
使用SVN的话
还是建议集成进eclipse来使用，资源库一同步
项目信息就一目了然了
为您推荐：
其他类似问题
java的相关知识
换一换
回答问题，赢新手礼包
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。
问题对人有帮助，内容完整，我也想知道答案
问题没有实际价值，缺少关键内容，没有改进余地
在使用git的时候有这样的需求：
发布版本，同时有脚本发布，直接提供一个脚本目录地址给运维，他们自己下载这个目录来执行。
我们有一个项目有多个模块，其中一个是前端的模块，前端开发的时候没必要把所有模块都下载下来，只需要下载模块即可。
以前使用svn,有svn export这样的功能。现在使用git,经过查询可以使用：
git archive --format=tar \ --remote=ssh://remote_server/remote_repository master | tar -xf -
我想直接不需要输入用户名密码的方式，如：
git archive --remote=http://username:password remote_server v6.2.8.6 ccms-web-builder/src/main/resources/sql/production/scripts |gzip -9 & scripts.tar.gz
但是遇到一个问题，这里git archive不支持http协议，因此运维或者前端在使用的时候，都要配置ssh，比较麻烦。
有没有其他比较好的方式能下载远程git仓库中单个目录的办法？
答案对人有帮助，有参考价值
答案没帮助，是错误的答案，答非所问
拆分成独立的repo，用submodule组织
关于免输用户名密码，配置公钥私钥就可以了
同步到新浪微博
分享到微博？
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）
我要该，理由是：
在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。我对 git 是不是有重大的误解,以及各位如何优雅地把本地完成的 javaweb 项目部署到服务器上呢?
· 65 天前 · 1571 次点击
我一开始以为 git 能够做到这样一个效果
比如我把服务器端的 /usr/local/tomcat7/webapps/SomeProject/这个文件夹作为一个远程 git 仓库
我本地的 java 项目所在的文件夹是一个本地 git 仓库
然后我编辑好这个 Java 项目，比如说弄了一个 a.jsp 吧通过 git 把这个项目推送到 /usr/local/tomcat7/webapps/SomeProject/，这样服务器端就有了这么个 a.jsp 。然后更新服务器端 tomcat，就能访问那个 a.jsp 了（ IP 地址 /SomeProject/a.jsp ）
这是我一开始对 git 的理解。。
====分割线===
但实际操作里我发现。在云服务器那边，如果新建一个仓库为裸仓库，那么推送过去的文件你实际上根本不知道在哪儿。我尝试在本地仓库新增了一个 test.txt ，然后 push 过去，我找半天都没有办法在服务器端直接找到这个 test.txt 文件。但是，我再从服务器端 clone 到本地另一个新文件夹，test.txt 就完整的回来了。。。也就是说裸仓库中不会直接出现推送过去的文件？那显然我的目的就达不到了啊。（ IP 地址 /SomeProject/a.jsp 可是 a.jsp 并不存在）
而如果新建一个非裸仓库在云服务器，它直接报错，我查了一下是因为 git 默认拒绝向非裸仓库进行推送。也就是说不支持这种行为。虽然好像能改参数改成支持，但我没改，因为 git 不支持这种行为，说明我一开始的那种需求并不是 git 想要完成的。
====分割线===
所以我现在就很迷。我也不是没搜索过，但就只能找到一些莫名其妙的或者太高深的内容。
我就奇了怪了，学习 java web 的人，难道就没有经历过如何优雅地把在本地编辑好地，运行 OK 的 java web 项目优雅地部署到服务器上去嘛？（用 FileZilla 这类软件，把本地的 javaweb 项目文件夹直接复制粘贴过去 OK 是 OK。。但就是不怎么优雅）到底应该怎么做啊？
& &65 天前 via Android
jekins 了解一下
& &65 天前 via Android
直接在服务器上撸 (被卡哭)…
& &65 天前 via Android
服务端的 git 仓库，默认是看不到目录文件的
git 应该管理的是源码，不是编译后的文件
服务器上用类似 Jenkins 的 ci，每次 git 推送后触发编译构建重新部署才对
& &65 天前
@ 服务器上撸还要部署图形化界面然后下载 IDE 才能编辑。。真的会被卡哭，而且我也只是破烂服务器。。
& &65 天前
几位学习 jekins 的时候看的什么书或者博客入门的呢？能推荐一下嘛？
& &65 天前
你确实有重大误解。git 不是文件同步用的。
& &65 天前
git 千万别放二进制文件
& &65 天前 via Android
bare 仓库应该是你需要的。不上 CI 工具，那就是自己在服务器放一个目录，同步代码到这个目录，执行完编译操作把资源文件放到 tomcat 的目录下
& &65 天前 via Android
@ 补充，就是 “你的电脑上的项目” 到 “ bare 仓库” 到 “服务器上的项目”
& &65 天前 via iPhone
裸仓库配合 hook 钩子应该满足你的要求
& &65 天前
@ Jenkins 超好用
& &64 天前 via Android
同意十楼 在 hook 里面可以写脚本拉取到最新的代码，然后部署
& &64 天前 via iPhone
git pull 了解一下？
& &64 天前 via Android
git 服务端只有.git 文件夹。一般是 push 进仓库后触发 hook，用脚本在 Apache/Nginx 监听的目录再 pull。（这时监听的目录也是一个 git 客户端）
& &64 天前
是重大误解。Git 是版本控制系统，和文件同步没有任何关系。
测试服务器同步可以考虑用 Syncthing，生产服务器部署应该用专业部署工具。
（比如 Ruby 圈子做部署应该用 mina 或者 capistrano。
& &64 天前
git 只用来管理源码，同步生产文件不是他该做的事
同步文件，可以手写 rsync，也可以用 ci，想做到自动化就结合 git 的 hook
& &64 天前 via Android
你的误解是可行的，我就是用 git 管理 java 的二进制部署。不要用 bare 部署，在部署的机器上 clone 一个普通仓库，然后 pull 加重启
& &64 天前
git hook 了解一下
& &64 天前 via iPhone
开发，打包，部署。别把 Git 用在不该用的地方
& &64 天前 via Android
idea sftp 目录映射，了解一下
& &64 天前
你需要在云服务器 clone 一个仓库，然后通过 bare 仓库的 git hook 在你本地 push 之后，在云服务器 clone 的那个仓库进行 pull 操作，最后在进行打包等其他操作。
& &64 天前
听起来楼主需要 sftp ？
& &64 天前 via iPhone
开发环境 测试环境 生产环境不一样的
& · & 2902 人在线 & 最高记录 3541 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.1 · 20ms · UTC 03:22 · PVG 11:22 · LAX 20:22 · JFK 23:22? Do have faith in what you're doing.7.4k 次阅读
标签：至少1个，最多5个
基础知识和命令先参考：
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
下面我们实战一下--no-ff方式的git merge：
git checkout -b dev 创建并切换到dev分支
vim readme.txt 修改readme.txt文件
git add readme.txt
git commit -m "add merge" 提交一个新的commit
git checkout master 切回master分支
git merge --no-ff -m "merge with with no-ff" dev 准备合并dev分支，注意--no-ff参数表示禁用Fast forward，因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去
git log --graph --pretty=oneline --abbrev-commit 合并后查看分支历史
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活
那在哪里干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如2.0版本发布时，再把dev分支合并到master上，在master分支发新版本
你和你的小伙伴每个人都在dev分支上干活，每个人都有自己的分支，时不时往dev分支上合并就可以了
所以，团队合作的分支看起来就像这个样子：
Git分支十分强大，在团队开发中应该充分应用。
软件开发中，bug就像是家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
当你街道一个修复代号为101的bug的任务的时候，很自然的，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交：
git status 查看状态
并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？
幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
git stash 用该命令查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心的创建分支来修复bug了。
git checkout master 从dev分支切换回master
git checkout -b issue-101
假定需要在master分支上修复，就从master创建临时分支
假设现在修复好了bug，本例中，就假如在readme.txt文件中做了修改
git add readme.txt
git commit -m "fic bug 101" 修改之后提交
git checkout master 从issue-101切换回master
git merge --no-ff -m "merged bug fix 101" issue-101 合并分支选择不适用Fast forward模式，然后添加必要的描述信息
git branch -d issue-101 删除issue-101这个临时bug修复分支
太棒了，bug搞定了，现在可以回到dev分支干活了
git checkout dev 切换回dev分支
git status 可以看出工作区是干净的，那么刚才的工作现场存在哪里呢？
git stash list 看到工作现场还在，Git吧stash内容存在某个地方了，但是需要恢复一下
方法一git stash apply，但是回复后，stash内容并不删除，你需要使用git stash drop来删除
方法二git stash pop，恢复的同时也把stas内容删除了
git stash list 再用git stash list查看，就看不到任何stash内容了
你可以多次stash，恢复的时候，先用giit stash list 查看，然后恢复指定的stash，使用如下的命令
git stash apply stash@{0}
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除。
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。
软件开发中，总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。
现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。软件开发中，总有无穷无尽的新的功能要不断添加进来。
添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。
现在，你终于接到了一个新任务：开发代号为Vulcan的新功能，该功能计划用于下一代星际飞船。于是开始准备工作
git checkout -b feature-vulcan 在dev分支上创建并且换到feature-vulcan分支，用来开发新功能
假如现在经过一定的时间后，工作完成了
git add vulcan.py
git status 查看状态
git commit -m "add feature vulcan" 提交
git checkout dev 切换回dev分支
一切顺利的话，feature分支和bug分支是类似的，合并，然后删除。但是，就在此时，接到上级命令，因经费不足，新功能必须取消！虽然白干了，但是这个分支还是必须就地销毁，不要再合并了:
git branch -d feature-vulcan 销毁失败。Git友情提醒，feature-vulcan分支还没有被合并，如果删除，将丢失掉修改，如果要强行删除，需要使用命令git branch -D feature-vulcan。
git branch -D feature-vulcan
当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin。
git remote 查看远程库的信息
git remote -v 显示更为详细的信息
git push origin master 推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上。
git push origin dev 也可以推送到其他的分支，比如dev分支
但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？master分支是主分支，因此要时刻与远程同步；dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。总之，就是在Git中，分支完全可以在本地自己藏着玩，是否推送，视你的心情而定！
多人协作时，大家都会往master和dev分支上推送各自的修改。
git clone :michaelliao/learngit.git
现在，模拟一个你的小伙伴，可以在另一台电脑（注意要把SSH Key添加到GitHub）或者同一台电脑的另一个目录下克隆。
git branch 当你的小伙伴从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支，所以执行这条命令只能看到master分支
git checkout -b dev origin/dev 现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支
git commit -m "add /usr/bin/env" 现在，他就可以在dev上继续修改，然后，时不时地把dev分支push到远程。
git add hello.py git commit -m "add coding: utf-8"
git push origin dev 你的小伙伴已经向origin/dev分支推送了他的提交，而碰巧你也对同样的文件作了修改，并试图推送。推送失败，因为你的小伙伴的最新提交和你试图推送的提交有冲突。
git pull 解决办法也很简单，Git已经提示我们，先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送。
git branch --set-upstream dev origin/dev git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接。
git pull 再次pull，这回git pull成功，但是合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样
git commit -m "merge & fix hello.py" git push origin dev 解决冲突后，再提交，再push
因此，多人协作的工作模式通常是这样的：
首先，可以试图用git push origin branch-name 推送自己的修改
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并
如果合并有冲突，则解决冲突，并在本地提交
没有冲突或者解决掉冲突之后，再用git push origin branch-name推送就能成功
如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。这就是多人协作的工作模式，一旦熟悉了，就非常简单。
18.标签管理
发布一个版本时，我们通常先在版本库中打一个标签，这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。
Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。
git branch 查看当前有哪些分支
git checkout master 在Git中打标签非常简单，首先，切换到需要打标签的分支上
git tag tagnamev1.0 打一个新标签
git tag 查看所有标签
默认标签是打在最新提交的commit上的（也就是HEAD）。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？
git log --pretty=oneline --abbrev-commit 方法是找到历史提交的commit id，然后打上就可以了，这时候显示了提交的历史信息 ，假如有这么一条就是你想打标签的历史commit：6224937 add merge
git tag tagnamev2.0 6224937 就可以给这次提交打标签了
git tag 可以查看标签信息，注意，标签不是按时间顺序列出，而是按字母排序的
git show tagnamev2.0 查看具体的某个标签的信息
git tag -a v0.1 -m "version 0.1 released" 3628164 还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字
git show v0.1 查看具体的某个标签的信息，可以看到说明文字
git tag -s v0.2 -m "signed version 0.2 released" fec145a 还可以通过-s用私钥签名一个标签，签名采用PGP签名，因此，必须首先安装gpg（GnuPG），如果没有找到gpg，或者没有gpg密钥对，就会报错
git show v0.2
用命令git show &tagname&可以看到PGP签名信息，用PGP签名的标签是不可伪造的，因为可以验证PGP签名。
git tag -d v0.1 假如标签打错了，也可以删除，因为创建的标签都只存储在本地，不会自动推送到远程。所以，打错的标签可以在本地安全删除。
git push origin v1.0 要推送某个标签到远程
git push origin --tags 或者，一次性推送全部尚未推送到远程的本地标签
git tag -d v0.9 如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除
git push origin :refs/tags/v0.9 然后，从远程删除。删除命令也是push，但是格式要注意
如何参与一个开源项目呢？比如人气极高的bootstrap项目，这是一个非常强大的CSS框架。
你可以访问它的项目主页，点“Fork”就在自己的账号下克隆了一个bootstrap仓库
git clone :yourname/bootstrap.git 然后，从自己的账号下clone
一定要从自己的账号下clone仓库，这样你才能推送修改。如果从bootstrap的作者的仓库地址:twbs/bootstrap.git克隆，因为没有权限，你将不能推送修改。
Bootstrap的官方仓库twbs/bootstrap、你在GitHub上克隆的仓库my/bootstrap，以及你自己克隆到本地电脑的仓库，他们的关系就像下图显示的那样：
如果你想修复bootstrap的一个bug，或者新增一个功能，立刻就可以开始干活，干完后，往自己的仓库推送。
如果你希望bootstrap的官方库能接受你的修改，你就可以在GitHub上发起一个pull request。当然，对方是否接受你的pull request就不一定了。
如果你没能力修改bootstrap，但又想要试一把pull request，那就Fork一下廖雪峰的仓库：，创建一个your-github-id.txt的文本文件，比如我的：xumenger.txt，写点自己学习Git的心得，然后推送一个pull request给他，他会视心情而定是否接受。
之前已经说过在使用之前必须先配置user.name和user.email，否则后面commit的时候可能会有错误，实际上git还有很多可配置的：
git config --global color.ui true 让Git显示颜色，会让命令输出看起来更醒目，自己去试试一些git命令的输出看看是不是有色！
有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配置文件啦，等等，每次git status都会显示Untracked files ...，有强迫症的童鞋心里肯定不爽。
好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的.gitignore文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。
不需要从头写.gitignore文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：
忽略文件的原则是：
忽略操作系统自动生成的文件，比如缩略图等；
忽略编译生成的中间文件、可执行文件等，也就是如果一个文件是通过另一个文件自动生成的，那自动生成的文件就没必要放进版本库，比如Java编译产生的.class文件；
忽略你自己的带有敏感信息的配置文件，比如存放口令的配置文件。
假设你在Windows下进行Python开发，Windows会自动在有图片的目录下生成隐藏的缩略图文件，如果有自定义目录，目录下就会有Desktop.ini文件，因此你需要忽略Windows自动生成的垃圾文件：
# Windows:
ehthumbs.db
Desktop.ini
然后，继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录：
*.egg-info
加上你自己定义的文件，最终得到一个完整的.gitignore文件，内容如下：
# Windows:
ehthumbs.db
Desktop.ini
*.egg-info
# My configurations:
deploy_key_rsa
最后一步就是把.gitignore也提交到Git，就完成了！当然检验.gitignore的标准是git status命令还会不会再说working directory clean。.gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！
使用Windows的童鞋注意了，如果你在资源管理器里新建一个.gitignore文件，它会非常弱智地提示你必须输入文件名，但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。
再次建议：有钱的买mac，没钱的用ubuntu--或者其他的linux发行版、被逼无奈的用Windows--但是被逼之余的自主时间一定要远离Windows。
给Git配置好别名，就可以输入命令时偷个懒。我们鼓励偷懒。
git config --global alias.st status 有没有经常敲错命令？比如git status？status这个单词真心不好记。如果敲git st就表示git status那就简单多了，当然这种偷懒的办法我们是极力赞成的。
git config --global alias.co checkout
git config --global alias.ci commit
git config --global alias.br branch
很多人都用co表示checkout，ci表示commit，br表示branch
git ci -m "bala bala bala..." 以后提交就可以简写成这样
git config --global alias.unstage 'reset HEAD' 在一节中，我们知道，命令git reset HEAD file可以把暂存区的修改撤销掉（unstage），重新放回工作区。既然是一个unstage操作，就可以配置一个unstage别名
git unstage test.py 当你敲入此命令，实际上Git执行的是：git reset HEAD test.py
git config --global alias.last 'log -1' 配置一个git last，让其显示最后一次提交信息
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)&%an&%Creset' --abbrev-commit" 甚至还有人这样的配置，那么，这时候git lg的效果是这样的
配置Git的时候，加上--global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。
配置文件放哪了？每个仓库的Git配置文件都放在.git/config文件中：
$ cat .git/config
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"]
url = :michaelliao/learngit.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
last = log -1
别名就在[alias]后面，要删除别名，直接把对应的行删掉即可。
而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中：
$ cat .gitconfig
co = checkout
ci = commit
br = branch
st = status
name = Your Name
配置别名也可以直接修改这个文件，如果改错了，可以删掉文件重新通过命令配置。
如果需要的话，请自己参考
14 收藏&&|&&101
你可能感兴趣的文章
沙发啊！顶楼主，继续推荐，我在本站也写了一点儿时也参考了很多。
沙发啊！顶楼主，继续推荐，我在本站也写了一点儿[ git
简介 ](http://segmentfault.com/a/3788)时也参考了很多。
你可能感兴趣的文章
分享到微博？
我要该，理由是：
在 SegmentFault，学习技能、解决问题
每个月，我们帮助 1000 万的开发者解决各种各样的技术问题。并助力他们在技术能力、职业生涯、影响力上获得提升。