Scm

回头想想老夫工作已两年余了，在这两年里面有一年半是用Git作为代码版本控制工具的，自从接触到Git，老夫可以说很快就成为了其一个脑残粉，被Git的易用性的强大功能所吸引，上周和我们team的小伙伴们分享了一下老夫以前Git的使用心得（当然分享的效果很不理想，实在是失误），还好老大赏识，让老夫结合自己之前的使用经验整理一个Git的开发规范流程，以供公司项目由SVN迁移到Git之后，大伙统一规范开发，刚好老夫也愿意趁此机会，整理一下自己的思路，结合自己以前使用经验，放在自己的Blog上，以供所有看到这篇文章的小伙伴参考，且大言不惭，定为：Git开发最佳实践。需要说明的是看这篇文章的人，老夫默认为对Git已经有了一定的基础，如果没有请看老夫之前写的这篇文章。 其实老夫窃以为Git的开发规范其实最重要的就是Git的分支管理，而分支又分远程分支和本地分支，本文将从远程应该存在哪些分支、本地应该存在哪些分支、为什么要存在这些分支、在这些分支上应该有哪些操作、这些分支的作用以及这些分支的生命周期一一说明。 一、远程 远程分支是由于我们开发人员在和同组小伙伴相互合并代码而生的，如果不是这我们可以不要远程分支，在远程应该存在三种类型的分支：master分支、feature分支和hotfix分支，记着这里说的是三种类型的分支而不是三个分支，下面将对此三种类型的分支一一解释。 master分支 首先说master分支的生命周期，master分支是生命周期最长的分支，他诞生于项目一开始，结束语项目的废弃，也就是master分支的生命是同步于项目的，只要项目存在就有这个分支； master分支上的操作：因为我们所有的操作都只能是在本地，所以远程分支实际上是可以认为没有任何操作的； master分支的作用：master分支①、是新建项目的默认分支，它不存在也就不存在项目，②、master分支上始终只能是最新的经过测试的可以正常跑的代码，③、每一个里程碑式的版本（可以理解为上线版本）都必须在此分支上打版本号，并注明为什么打此版本号，以供运维上线和将来万一回滚之用，同样也是我们查询我们每一次上线版本历史记录的依据； 为什么要有master分支：同步项目生命而默认而存在的，不可能没有，也不能没有。 feature分支 feature分支是功能分支，开发新功能的时候创建，所以feature分支永远应该（记得是应该）是依托于最新版本的master上分支的代码而建立的，该master可以是远程master也可以是本地master分支，后面我会说明原因； feature分支的生命周期，feature分支生命周期应该是仅次于master分支的，他在我们开发新功能的时候创建，在我们完成新功能（即完成了测试等一系列流程，可以上线了）的时候生命终止，为避免远程分支太多太乱，可以删除； feature分支上的操作：上文已经说过远程分支实际上是可以认为没有任何操作的； feature分支的作用：就是我们基于最新代码开发新功能而用，仅此而已； 为什么存在feature分支：一言以蔽之，基于我们开发新功能时不相互影响，具体来说虽然没有此分支也是可行的，但如果不存在该分支，可能的后果，team中A开发了一个新功能，直接提交到了master上，测试人员在测试中，此时team另一个成员B开发了另一个新功能也提交到了master上，并且测试也已经完成，需要紧急上线，但由于master上有A提交的未经测试的代码，上线就会存在风险，如果不上线，大家都懂得，故必须存在此分支。 注：feature分支是开发新功能的时候创建的，所以如果我们同时开发多个新功能，那么远程就会同时存在多个feature分支 hotfix分支 hotfix分支可以理解为线上代码出现紧急bug时，为修复此bug为紧急建的一个分支，因为是为修复线上系统出现的紧急bug而生，所以其也应该是依托于最新版本的master分支上的代码而建立的。 hotfix分支因为是为修复紧急bug而生，那么其生命周期是随bug的出现而出现，随bug的修复而终止； hotfix分支也是远程分支，同样可以认为没有任何操作； hotfix分支的作用，自然就是修复线上系统出现的紧急bug而生； 至于为什么存在该分支，看了上面就不用多说了吧； 好了，远程的三种类型的分支说完了之后，我们就应该说本地存在哪些分支了 二、本地 本地是我们开发人员在本地为开发各种新功能、修各种bug而建的分支，我们开发人员所有的操作可以认为都是在这些分支上，同样和远程存在多个分支一样，本地也会存在多种类型的分支：master分支、feature分支、hotfixe分支和dev分支，同样这里说的是四种类型的分支而不是四个分支，下面同样对这些分支一一说明。 master分支 不错，不仅只有远程有master分支，本地也有一个master分支和远程对应，其的出现也是在我们clone远程分支时而默认出现的，既然本地master是和远程master分支对应的，所以他的生命周期也是显而易见的； 在这里也可以解释一下，远程feature和hotfix为什么既可以基于远程master分支而建，也可以是基于本地的，因为本地的master分支是和远程对应的； 本地master分支上的操作：在本地master分支只允许出现四种操作：pull、push、merge、rebase，其余的一律不允许出现，记着这个要求还是非常高的，另外他pull的是远程master分支上的代码，push也是把本地master分支上的代码推送到远程master分支上，而merge和rebase当然是merge和rebase的feature分支了； 本地master的作用：1. 除非本地没有代码，否则本地就会出现该分支，但不出现又有什么意义呢，2. 合并其他已经开发完成的feature分支，然后把这些代码一并推送到远程master分支上，3. 在本地master分支上新建tag，并把这些tag推送到远程，供运维上线； 为什么存在该分支，也不用说了吧。 feature分支 同样本地feature分支是和远程feature分支对应，在我们开发新功能的时候，不可能只有一个远程的分支，而本地没有，因为如果本地没有的话，我们又怎么开发呢，所以这就是为什么存在本地feature分支； 看了存在本地feature分支之后，本地feature分支的生命周期也就出来了，和远程feature分支是一样的； 本地feature分支的操作：在本地feature分支上，原则上只允许存在：pull、push、merge、rebase，记着这是原则上，并没有本地master分支的要求高，在本地feature分支行如果有其他操作也是可以的，但之所以这么要求只要出现这四种操作，是为了将来和同组的小伙伴合并代码方便，如果不这么做代码也是能合并的，但如果一旦出现冲突，合并起来会稍麻烦。 需要说明的，本分支push到的是远程feature分支，pull的也是远程feature分支，而merge和rebase的是基于其建的dev分支的代码 hotfix分支 有了本地master分支和本地feature分支的说明，所以聪明人肯定猜出来了，本地hotfix分支也是和远程hotfix分支是对应的，那么生命周期自然相同； 相信从上面的说明中，和这些分支名字上我们就可以看出，hotfix和feature分支本质上是一样的，仅仅是feature分支是开发的一个大功能，需要多人协作多天才能完成，而hotfix大多都是一些比较紧急的、需要立马修复的一个小功能而已，所以在他上面的操作一个是和feature分支一样的，存在的原因自然是为了修复线上紧急bug而存在的。 dev分支 说完了以上三种类型的分支，下面就是最常见的dev分支了，他是没有一个分支和远程对应的，他也是我们开发中日常操作的一个分支； 根据上面的说明，无论是开发一个新功能还是修复一个紧急bug是，都会在本地建一个对应的分支，而在这些分支上只允许出现那四种操作，所以其他的操作就只能在这个分支上了，也就是说，我们在开发一个新功能的时候，我们应该基于本地的feature分支创建一个dev分支，在这上面开发我们的新功能，开发完成后合并到本地feature分支上，然后推送到远程feature分支上，供测试人员进行测试，测试人员对该新功能测试完成后，合并到本地master分支上，最后一并推送到远程master分支上，打tag，上线。 说完了，远程、本地应该有哪些分支，这些分支的作用、生命周期之后，下面列出一些要用到的几个重要的命令 三、分支管理用到的几个最重要的命令 本地master分支推送到远程，也就是创建远程分支 feature git push origin master:feature 注意此命令的“冒号”前后不要加空格，否则会报错。当然也可以用下面的命令，也是我习惯的命令，先在本地基于 master 分支创建 feature 分支，然后把本地 feature 分支推送到远程，也就是现在 master 分支上执行第一个命令，会创建本地并切到 feature 分支上，然后在本地 ferture 上执行第二个命令 git checkout -b feature git push origin feature:feature 当然创建远程 feature 分支，除了用命令外，还可以是用 Gitlab 和 gerrit 的 web 界面创建 ...

作为一个程序猿，你一定听说过世界最大的同性交友网站：GitHub，但对于其怎么使用，可能会有一点陌生，今天老夫就把自己平时积累的一点经验记录一下，同时分享给大家，需要说明的是，老夫对于很多操作也不甚了了，希望高手能多多留言交流。要想在世界上最大的同性交友网站上畅游，第一步当然是注册啦，但怎么注册老夫就不说了，和其他的注册没有什么差别，下面我们就从Git的客户端下载、安装和配置说起。 一、Git客户端的下载与安装 Windows安装msysgit 选择Git-1.x.x.x-xxxx.exe Linux安装sudo apt-get install git 安装完成之后，桌面上会有一个“Git Bash”的快捷方式，双击打开，我们一下的操作，将主要在这里完成 二、Git客户端的配置 配置用户名 git config –global user.name username 配置邮箱 git config –global user.email email SSH Key配置 我们可以通过两种协议在这个世界上最大的同性交友网站里畅游，但我们一般都是通过SSH协议，所以我们下面要配置SSH Key，在配置SSH Key之前，我们可以先敲一下下面这个命令： ssh -T git@github.com 这个命令一方面可以测试我们与这个世界上最大的同性交友网站的通信是否顺畅，另外如果显示出了你在Githu上的用户名，则表示已经配置过了，不需要再生成SSH Key了； 如果没有配置过，那好下面我们就要生成SSH Key了，生成SSH Key的命令： ssh-keygen 使用该命令，一路Enter下去，就会在C:UsersAdministrator.ssh目录下，生成一对SSH key，生成SSH key之后就需要我们将公钥添加到Github上了，方法： 打开C:UsersAdministrator.ssh目录，使用Notepad++等现代文本编辑器（记事本就算了，而且还可能遇到问题）打开id_rsa.pub文件，将里面的内容全部拷贝下来，然后打开Github，打开个人设置页面，选中“SSH Key”选项，点击“Add SSH Key”按钮，然后在新新出现的表单中，填入标题，再将刚刚复制下来的内容，粘贴到“Key”栏，然后点击“Add Key”按钮，完成添加，此时我们可以再次敲一下： ssh -T git@github.com 测试是否配置成功，如果成功了，那么我们就真的可以再这个世界上最大的同性交友网站上畅游了 三、把本地项目放到GitHub上 既然是把本地项目放到GitHub上，那么我们先在Git上建一个仓库，例如：Demo，然后我们在本地的项目，也就是Demo下执行以下命令： git init git add README.md git commit -m "first commit" git remote add origin git@github.com:bridgeli/Demo.git git push -u origin master 如果是我们一个人在玩的话，当我们在做出一些修改之后，以后的操作就可以直接： git add README.md git commit -m "first commit" git push -u origin master 其中 add 后面跟的是文件名，如果提交所有也可以使用命令： ...

作为一个软件开发人员，关于scm的重要性和必要性，相信我不用说了，目前最流行的的两个版本控制工具svn和git，关于这两个区别还是很大的，而git功能更强大，猜测以后会越来流行，在svn作为打败众多SCM工具的一个版本控制系统，他目前的使用还是非常多的，而且操作也非常简单，所以这一节就写一下svn服务器的搭建，有机会将来在写一篇关于git烦人使用的文章。好了，下面进入今天的正题： 首先推荐大家下载Subversion，随便哪个版本都行，安装过程就不说了，可以说是一路next，那么服务器就转好了，下面经过一些设置就可以使用了。 注：可以再cmd中敲一下 svn，看是否安装好了 第一步：在服务器上建立核心仓库，这个很简单，就一个命令 svnadmin create svnrepo 其中svnrepo就是我们的核心仓库，在那个路径下敲，那么这个仓库就会在哪个路径下，那么我们放东西的大仓库就建好了，另外名字我们可以随便写，自己看着什么顺眼就起什么，不过最好做到见名知意 第二步：权限设置，即哪些人可以访问，哪些人不可以访问，这个也很简单，我们进入第一步创建的svnrepo文件下，然后进入conf文件夹，打开svnserve.conf文件，这个文件保存着svn的常见设置， 我们首先找到 \# password-db = passwd 这一行，把前面的注释去掉，也就是把#去掉，最好连空格一块去掉。这个是说明，如果访问我们的服务器，需要在另一个文件中，即passwd文件中配置，同时我们也可以找到这两行: \# anon-access = read \# auth-access = write 也就是匿名访问的权限，匿名访问我们最多给他只读的权限，这个随你的便。 第三步：既然第二步说了我们的密码在passwd文件重配置，那么肯定是打开这个文件，进行配置了，我们可以看到默认有两个人，而且这两个人也是注释掉的，我们可以在下面加自己的用户，前面是用户名和密码，例如： bridgeli = abc123_ 注意两点，1. 这个用户名前面一定不要有空格，否则svn会认为这个用户的名字带空格，很别扭； 2. 你们项目组，有几个人你就填加几个用户名啦，那么这样大家都可以有自己的用户名去提交代码了。 第四步：svn的仓库，我们建好了，配置也做好了，那么现在肯定是把服务器起起来了，起服务器的命令如下： svnserve -d -r svnrepo 其中-d代表后台启动，-r代表root用户，相信知道Linux的对这个用户一定不陌生。svnrepo，就是我们的仓库名。 切记：这个窗口一定不要关，如果关了那么服务器就关了。 那么到此为止，我们svn服务器就建好了，大家就可以往里面提交代码了，但是但是大家有没有发现一个问题，我们很随便就可以提交代码了，大家在提交代码时，有经验的项目经理，一定会要求手下每个提交代码的同学，写上注释，如果不做限制，就这样那么问题就来了，总有人会无意中忘了怎么办？那么我们是不是可以在服务器端限制一下要求所有人必须提交代码呢？答案是肯定可以的。（其实在TortoiseSVN客户端也是可以的，但是但是大家都懂得，在客户端设置这个就太不靠谱了），下面给出在svn服务器端的设置，那么大家就必须在提交时必须写注释了 我们在我们的仓库中的hooks文件夹中，找到pre-commit.tmpl文件，在windows下可以修改这个文件为pre-commit.bat，然后把里面的内容修改为如下： @echo off setlocal set REPOS=%1 set TXN=%2 rem check that logmessage contains at least 10 characters rem …..代表5个字符 svnlook log "%REPOS%" -t "%TXN%" | findstr "………." > nul if %errorlevel% gtr 0 goto err exit 0 :err echo Empty log message not allowed. Commit aborted! 1>&2 exit 1 修改为bat相信大家都知道让Windows知道是可执行文件，据说不加后缀也可以，关于这个我没有测试过，大家可以自己测试，在测试之前呢，为了避免库被破坏，我们可以自己先备份一下。