私有Git版本库的搭建和使用（初探）

yzc164

　　本文章为抛砖引玉，可能有概念或理解错误，恳请读者斧正！
　　要做毕业设计了，想把毕业设计作为一个项目好好做一下，在公司实习了半年也对项目开发的流程有了一定的了解，那么一个正式的开发项目通常都会使用一种版本控制系统，有了版本控制系统一方面可以记录每次对代码编写和修改的操作，另一方面也可以很方便的对代码进行备份，如果有机会发展成开源项目的话，也可以直接变成公共版本库，然后成立开源社区，广受业内关注，最后达到技术的巅峰（想想还有些小激动呢～）。
　　咳咳～常见的版本控制基本上有SVN、CVS（传说是SVN的前身）、Git。在实习单位使用CVS使用到吐，功能很局限，而且经常莫名其妙地或因为一个空行爆出代码冲突；至于SVN嘛——哼哼，每一个文件夹下有个配置文件，不小心动了配置文件就可能会发生错误，而且还要现安装和配置，个人技拙，之前在学校里配置SVN的服务端配置了好久都没成功；Git的分布式特性虽然我个人开发的时候用不到，但是Git既小巧、又完善，而且在大多Linux发行版下是预装的，所以我选择用Git。
　　据说如果以前没有用到任何版本控制系统的人去学Git是比较容易的，反而如果用过其他版本控制系统就不是很容易理解Git的思想了（我恰恰就是这种情况）。因为Git与其他的如CVS在思想上是完全不同的。说起不同，哼哼，也没什么，就是分支（Branch）机制，你会发现在你使用的过程中充斥着各种各样的分支，比如服务器上一个版本库中就有稳定分支和Nightly分支（程序员多是夜喵子？），Clone下来的版本库一般也有服务器上的所有分支，自己改写代码要新建分支，改完代码要清理、切换和合并分支，尝试不同思路还要多建几个分支，改代码改到吐果断删除分支……囧
　　好吧，再吐槽呆毛就啵儿起了，我们言归正传。大体需求是酱紫的：
　　1.因为是我的毕业设计，在被指导老师虐完之前不希望其他人各种拉来、推去、吐槽和卖萌，所以我希望我的版本控制系统是私有的。
　　2.有人说在新建的分支上编写和修改代码有助于使主干（master）的提交记录更加“干净整洁（clean history）”，所以我要在本地创建至少一个工作分支。
　　3.前段时间内心深处和被窝里都充斥着空虚寂寞冷，终于按捺不住燃起了熊熊烈火—→_→—在DigitaloCean上买了个VPS，所以我希望可以在服务器上有一个远程版本库作为备份。
　　那么根据我这两天的学(zhē)习(teng)，大体了解了Git的使用流程，做出结构设计如下（莫喷，多提建设性意见）：

　　下面是我的搭建过程：
　　

#服务器上：　　

　　
#创建一个文件夹，用于存放项目
　　

mkdir /home/libook/Git/myProject　　

　　
#进入这个文件加
　　
cd
/home/libook/Git/myProject　　

　　
#创建一个空的版本库，这种版本库单纯作为版本的储存，不能用于修改代码（实际上根本看不到代码），但是能被clone或pull成可以进行开发的源代码版本库
　　
git init
--bare　　

　　

#本地上：　　

　　
#进入你的代码目录，假设情况是这样
/home/libook/Documents/theProject/myProject/各种代码和目录　　
cd
/home/libook/Documents/theProject　　

　　
#初始化Git，下面这个语句会在theProject下生成一个.git目录
　　
git init
　　

　　
#创建一个筛选规则，用来忽略一些我们不想加入到版本库中的文件或目录，具体筛选规则请自行搜索
　　
vim .gitignore
　　

　　
#将源代码和目录结构添加到Git中，还有别忘了.gitignore文件
　　
git add .
/myProject　　
git add .
/.gitignore　　

　　
#提交刚刚做的操作
　　
git commit
-m "写点说明描述神马的"　　

　　
#[可选]看一下版本库状态，是否有问题
　　
git show
　　

　　
#[可选]看一下刚刚提交的记录
　　
git log
　　

　　
#添加远程服务器上的版本库；最后一个斜杠“
/”千万不能丢！！；指定一个别名gitserv，以后就可以用这个别名来直接进行远程操作了；另外我使用的是SSH协议，也可以用其他的协议，自己搜索啦2333～　　
git remote add gitserv
ssh://用户名@IP/home/libook/Git/myProject/　　

　　
#将本地版本库提交到服务器上去，由于我们一般只提交主干，所以指定分支的地方就写master
　　
git push gitserv master
　　

　　

#服务器上　　

　　
#[可选]看一下版本库状态，是否有问题
　　
git show
　　

　　
#[可选]看一下刚刚提交的记录是否Push上来了
　　
git log
　　

　　搭建完成，那么平时使用的时候怎么用呢？
　　大体使用流程是这样的：
　　

#本地上：　　

　　
#进入版本库目录
　　
cd
/home/libook/Documents/theProject　　

　　
#[可选]切换到主干，一般默认就是在主干上
　　
git checkout master
　　

　　

#本地上：　　

　　
#[可选]这块是与服务器同步一下，由于目前是我自己用，所以这步骤可以忽略：
　　

　　
#把远程服务器上的主干(master)同步到本地的临时分支(如tmp)
　　
git fetch gitserv master:tmp
　　

　　
#看看是否有别人改过代码
　　
git
diff tmp　　

　　
#如果有人改过的话在同步之后需要把tmp合并到主干上
　　
git merge tmp
　　

　　

#本地上　　

　　
#[可选]上面这块基本上等价于
　　
git pull gitserv master
　　

　　

#本地上　　

　　
#创建分支
　　
git branch 分支名
　　

　　
#切换到分支
　　
git checkout 分支名
　　

　　
#修改代码
　　
######################
　　

　　
#[可选]每修改完一个文件，保存后需要更新这个文件的快照
　　
git add 文件名
　　

　　
#提交代码（这个步骤可能会执行多次）
　　
git commit
-m "写点什么描述"　　

　　
#如果之前修改的文件没有用git add进行更新，那么可以使用下面的语句自动更新、提交（这个不会更新没有git add过的文件）
　　
git commit
-a -m "写点什么描述"　　

　　

#本地上　　

　　
#将工作分支上的修改记录合并到主干上
　　

　　
#切换到主干
　　
git checkout master
　　

　　
#方法1：将分支上所有的提交记录合并到主干，在主干上保留分支合并的记录
　　
git merge 分支名
　　

　　
#方法2：将分支上所有的提交记录压缩成一条提交记录合并到主干，在主干上保留此分支合并的记录
　　
git merge
--squash 分支名　　

　　
#方法3：衍合，将分支上所有的提交记录作为一个个补丁合并到主干，主干上没有此分支合并的记录，只有提交记录
　　
git rebase 分支名
　　

　　
#以上合并方式出现冲突后查看冲突
　　
git status
　　

　　
#衍合分支解决冲突后继续衍合
　　
git rebase
--continue　　

　　
#衍合分支出现冲突后撤销衍合
　　
git rebase
--abort　　

　　

#本地上　　

　　
#删除分支
　　
git branch
-d 分支名　　

　　

#本地上　　

　　
#把本地的主干推送提交到远程版本库上
　　
git push gitserv master
　　

　　需要说明的是网上好多人都在呼吁与远程版本库同步的时候尽量不用pull，尽量用fetch，因为那样可以看看服务器上的代码被别人改成了啥尿性，然后再取舍合并。还有，其实fetch有丰富的选择分支进行同步的功能，还有删除分支的功能，具体这里就不细谈了。
　　关于merge和rebase，我个人也不是特别理解，不过我知道rebase一般用在自己私下写的分支。假设自己在主干分了一个work分支，这个work分支又分了3个分支，且没有向公共版本库推送过，那我完全可以在写写改改后用rebase把这三个分支合并到我的work分支上；这个work分支会很干净，只有一条线，没有之前的3个分支的历史记录，但是之前3个分支的提交记录都保留在了work的提交记录里；就好像从来没有这3个分支，所有提交记录都是我这个work分支上完成的；然后我们就可以用merge把这个work分支合并到主干上。再设想一下，如果我们把其他人的分支同步了下来，然后修改了一下，再rebase到主干上，那么这个分支在主干上就不存在了，如果别人已经正在用这个分支开发的话，那么他在经历了蛋疼地调式和编码之后就会呵(mā)呵(bī)地发现自己的分支不存在了，可能还要重新做一遍这个分支（此乃居家旅行恶作剧找喷找打找死必备～～）。
　　另外，git所有功能的man手册都挺详细的，特别是rebase还有图示，只是没过CET-4的鄙人看着有点麻烦。当然，M$党就没这福分了。。。
　　本文章系受著作权法保护,未经著作人同意,不得盗用；使用或引用本文章内容请注明作者名、原地址：书中叶http://www.cnblogs.com/libook