Git

今天的文章比较简单，1. 就是为 Git 单个项目做身份配置，就是配置单独的邮箱和用户名。因为我们平时可能会在不同的几个项目中工作，各个项目的用户名可能不同，最基本的就是公司的项目和我们自己在 GitHub 上玩，所以为了保证日志的准确性和提交时无误，最好对各个项目设置。以前没有研究过，所以就一只默认用公司的用户名玩，但一直感觉不太好，2. 在提交时，user.name, user.email会进入日志。这些信息，是追踪代码变更的关键，所以必须配置，偶然看见秋大有篇文章写这个，试了一些不错，记录一下。 全局配置和项目配置 全局配置信息在: ~/.gitconfig 项目配置在项目目录下的： ./.git/config 配置多个用户身份 git config –global 操作全局配置, 不带 –global 选项的话，会尝试相对于当前目录下找：./git/config, 找不到的话，报错，所以如此一来，我们就可以： \# for global setting git config &#8211;global user.name xxx git config &#8211;global user.email xxx@xxx.com \# for repository git config user.name xxxx git config user.email xxxx@xxx.com 另，我们都知道 Linux 下，我们可以通过 alias 命令设置别名（之前一直就不住这个命令，每次都是查一下，后来一朋友说多好记啊 ali as，阿里 as，就再也忘不了了），我们可以通过一个短命令把 git 日志重新格式化一下，至于其他的像：git status，git commit 是否重命名就看习惯了（看过有人把常错的单词都重命名为正确的，省时间，机智） git config &#8211;global alias.lg "log &#8211;color &#8211;graph &#8211;pretty=format:&#8217;%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset&#8217; &#8211;abbrev-commit &#8211;" 强制检查各个项目用户名邮箱设置 使用 pre-commit 钩子进行检查，所以在 .git/hooks 中添加一个 pre-commit 文件（注意权限），内容如下： ...

之前的文章曾写了Git怎么用和Git服务器怎么搭建，一个公司仅仅只有这些还是远远不够的，这些仅仅是对源码的管理，程序猿开发好的源码怎么编译、打包、部署上线呢？下面就需要运维来解决这个问题了，不过这一段时间公司老大让老夫负责公司的源码由SVN迁Git，有幸接触到一点这块的知识，今天记录一下，万一老夫哪天失业了转行去做运维了呢！ 在开始正式文章之前，首先感谢一下我在小马金融的同事：张学军，此脚本原始版本是由学军提供的，然后加上老夫的优化，可以说没有学军的无私帮助，老夫不可能完成这个脚本的，所以，谢谢，学军！ #!/bin/bash export JAVA_HOME=/usr/local/jdk1.7.0_67 export JRE_HOME=${JAVA_HOME}/jre export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib export PATH=${JAVA_HOME}/bin:$PATH dir_path="/apps/project/project_name" work="project_name" DATE=\`date +%Y%m%d%H%M\` tomcat="apache-tomcat-6.0.41_project_name" cd $dir_path if [ ! -d wars ];then mkdir wars fi if [ -d ROOT ];then tar cfz ROOT-$DATE.tar.gz ROOT mv ROOT-$DATE.tar.gz wars/ fi git_update(){ tag_version=$1 cd $dir_path/$work git checkout master git pull echo $tag_version git_tag=\`git tag|grep -x $tag_version\` if [ "$git_tag" = "$tag_version" ];then git checkout -b \`date +%Y%m%d%H%M\` $git_tag else printf "tag number input error n" exit 1 fi git_id1=\`git log -1 &#8211;format=%H\` git_id2=\`git show $git_tag |grep commit |awk &#8216;{print $2}&#8217; |head -1\` if [ "$git_id1" != "$git_id2" ];then printf "The current git branch where inconsistent tag number is correct , please check the tag number n" exit 1 fi } tag_version=$1 if [ "$tag_version" = "" ];then printf "Please enter the version number n" exit 1 else git_update $1 echo $1 >> ${dir_path}/tag.txt fi build(){ dir_path=$1 work=$2 cd $dir_path/$work mvn package -DskipTests if [ -d $dir_path/$work/target ];then cd $dir_path/$work/target else echo "build $dir_path/$work failed" exit fi return 1 } build $dir_path $work type=$? if [ $type -eq 1 ];then cd $dir_path/$work/target work_name=\`ls |grep $work |grep -v "war|jar|gz"\` else echo "build failure" exit 1 fi if [ -d $dir_path/ROOT ];then rm -rf $dir_path/ROOT fi cd $dir_path/$work/target/ mv $work_name $dir_path/ROOT if [ -d $dir_path/ROOT ];then scp $dir_path/config.properties $dir_path/ROOT/WEB-INF/classes/ scp $dir_path/redis.properties $dir_path/ROOT/WEB-INF/classes/ scp $dir_path/jdbc.properties $dir_path/ROOT/WEB-INF/classes/ fi tomcat_status=\`ps aux |grep $tomcat |grep -v "gerp">/dev/null;echo $?\` if [ $tomcat_status -eq 0 ];then kill -9 \`ps aux |grep $tomcat |grep -v "grep"|awk &#8216;{print $2}&#8217;\`;rm -rf /usr/local/$tomcat/work/\*;rm -rf /usr/local/$tomcat/temp/\*;/usr/local/$tomcat/bin/startup.sh else rm -rf /usr/local/$tomcat/work/\*;rm -rf /usr/local/$tomcat/temp/\*;/usr/local/$tomcat/bin/startup.sh fi 注：里面的project_name是项目名，老夫隐藏了公司的实际项目名，就以project_name代替了，实际用的时候请根据实际情况修改 ...

公司的代码托管打算由SVN迁移到Git，刚好老大让老夫全权负责这个事(感谢老大信任)，老夫根据自己使用Git的经验，选择了Gerrit作为服务器，下面介绍一下老夫搭建Gerrit服务器的过程及第一次使用时需要注意的事项，如果以前没有用过Git可以参考老夫之前写的这篇文章和这篇文章。 环境准备 ①. Linux，Gerrit需要Linux环境，至于是哪个发行版本就不重要了，ubuntu还是centos随意； ②. JDK，这个怎么安装就不说了，Java程序猿都会，就是不会网上一搜一堆，不做赘述； ③. MySQL，其实这个非必须，Gerrit自带的有H2数据库，但没法老夫就是喜欢MySQL； ④. nginx，作为认证和反向代理服务器； ⑤. Maven, 在安装的过程中会下载一些jar文件； ⑥. Git，这个忘了是不是必须的了，但还是装上吧，反正也不多，大家可以自己试一下需不需要（欢迎留言指出）； 数据准备 ①. 自己去Gerrit的官网：http://gerrit-releases.storage.googleapis.com/index.html，下载一个合适的版本，就是一个war包，这也就是我们为什么需要先装JDK的原因，需要说明的是Gerrit的1.X版本是Python写的，2.X改成了Java，变成了一个war包； ②. 为Gerrit创建一个数据库，库名您随意，最好有意义，例如就叫reviewdb 开始安装 开始安装之前，有人建议专门为Gerrit创建一个用户用户运行Gerrit，并且禁止登陆，这里从简，如果你非要这么做可以这么做： adduser gerrit2 passwd &#8211;delete gerrit2 然后以gerrit2运行安装，老夫就从简了，直接敲一下命令： java -jar gerrit-xxx.war init -d review gerrit-xxx.war就是你之前下载的war包，review是一个路径，就是安装到这下面，你可以随意定义，敲完这个命令，就进入一下交互(你的可能不太一样)，在里面我加了一些注释： Gerrit Code Review xxx 选项中大写字母为默认选项,如使用默认选项回车即可 Create &#8216;/home/review&#8217; [Y/n]? Git Repositories gerrit用于存储git仓库的目录,相对于根目录review #就是之前-d后面的路径 Location of Git repositories [git]: SQL Database Database server type [h2]: mysql #数据库选mysql Server hostname [localhost]: Server port [(mysql default)]: Database name [reviewdb]: Database username [root]: root&#8217;s password : confirm password : User Authentication 使用HTTP认证,OPENID需要服务器连接互联网,还可以使用LDAP认证服务 Authentication method [OPENID/?]: http #这里建议选http Get username from custom HTTP header [y/N]? SSO logout URL : Email Delivery gerrit发送邮件设置,可以使用本地或远程SMTP服务器, 只要在smtp服务器上有帐号即可。 SMTP server hostname [localhost]: #这里我并没有选择邮件发送服务器和其他的配置，不知道为什么也可以发邮件 SMTP server port [(default)]: #事实上发邮件是必须的，有知道为什么，可以告知，谢谢 SMTP encryption [NONE/?]: SMTP username [root]: root@localhost.localdomain&#8217;s password : confirm password : Container Process 使用root用户运行gerrit Run as [root]: Java runtime [/usr/lib/jvm/java-7-openjdk-amd64/jre]: Copy gerrit-2.8.1.war to /home/review/bin/gerrit-xxx.war [Y/n]? Copying gerrit-2.8.1.war to /home/review/bin/gerrit-xxx.war SSH Daemon gerrit自带的ssh服务,与服务器自身的ssh服务无关,监听默认端口即可 注意:如要使用低于1024的特权端口,需authbind授权,否则ssh会绑定端口失败 Listen on address [*]: Listen on port [29418]: Gerrit Code Review is not shipped with Bouncy Castle Crypto v144 If available, Gerrit can take advantage of features in the library, but will also function without it. Download and install it now [Y/n]? Downloading http://www.bouncycastle.org/download/bcprov-jdk16-144.jar &#8230; OK Checksum bcprov-jdk16-144.jar OK Generating SSH host key &#8230; rsa&#8230; dsa&#8230; done HTTP Daemon 这里使用nginx反向代理gerrit,所以只在loop接口监听即可。 如果使用域名访问gerrit,最好将规范URL设置为域名形式,发送校验邮件时会使用到 Behind reverse proxy [y/N]? y Proxy uses SSL (https://) [y/N]? Subdirectory on proxy server [/]: Listen on address [*]: 127.0.0.1 Listen on port [8081]: Canonical URL [http://127.0.0.1/]: Plugins 选装插件 Install plugin download-commands version v2.8.1 [y/N]? Install plugin reviewnotes version v2.8.1 [y/N]? Install plugin replication version v2.8.1 [y/N]? Install plugin commit-message-length-validator version v2.8.1 [y/N]? Initialized /home/review Executing /home/review/bin/gerrit.sh start Starting Gerrit Code Review: 因为为ssh服务选在了低于1024的端口,且没有authbind端口授权,所以会出现如下错误,高于1024端口不会。 FAILED error: cannot start Gerrit: exit status 1 Waiting for server on 127.0.0.1:80 &#8230; OK 服务器上没有X,所以使用浏览器打开连接失败 Opening http://127.0.0.1/#/admin/projects/ &#8230;FAILED Open Gerrit with a JavaScript capable browser: http://127.0.0.1/#/admin/projects/ 到了这里只能说好了一半，如果你直接通过域名访问，会报一个认证失败的错误，错误就不贴了，大家自己看看就知道了 需要说明的是，以上这些配置，也可以通过修改：review/etc/gerrit.config 进行修改，修改之后重启就好了 ...

回头想想老夫工作已两年余了，在这两年里面有一年半是用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 &#8211;global user.name username 配置邮箱 git config &#8211;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 后面跟的是文件名，如果提交所有也可以使用命令： ...