软件工具 on 有点稳

初识log4j

Tue, 09 Aug 2016 00:00:00 +0000

log4j有三个主要的概念：记录员loggers、录入笔appenders和录入风格layouts。

记录员是分级别、继承式的。每个记录员有三个基本特征：

名称的继承除总记录员之外的所有记录员都要有名称。名称往往是全路径类名，例如com.foo.Bar。名称的继承是指记录员之间有继承关系，com.foo是com.foo.Bar的父亲，com是com.foo.Bar的爷爷。每个记录员的名称唯一，并且能够通过getLogger方法直接被获取。每个记录员在第一次被获取时被实例化，总记录员除外，它始终都存在，所有没父亲的记录员都继承自它。

每个记录员都有记录级别，默认系统给出的级别，分六档，从低到高依次是跟踪TRACE、调试DEBUG、记录INFO、警告WARN、错误ERROR、灾难FATAL。使用者被允许自定义新的级别，但不被建议，通常这六种也足够用了。

级别的继承记录员的级别有两种方式取得，一种是使用者用setLevel直接指定，另一种是从祖先那里继承。直接指定就不必说了，继承也很简单，自己如果没被指定级别，那就继承父亲的级别，如果父亲还没有，那就继续向上，直到有祖先被指定级别。总记录员必须被指定级别，因为没有父亲了。
赢得纪录权利的规则记录员的每一次记录信息都有级别检查，记录信息的级别由记录方法决定，比如，默认的六个方法trace, debug, info, warn, error, fatal。记录员用比自己级别低的记录方法，不会有信息输出，只有用了高级别（大于等于自身级别）的记录方法才会输出。还有个一般性的记录方法log，可以通过指定级别，随意变身默认的六种方法。所以记录员赢得记录的权利就是调用比自身级别高的记录方法。

录入笔 记录员只有方法没有工具也不知道把信息记到哪儿，录入笔就是这个工具。每个记录员可以有多个记录笔，不同记录笔记录到不同的平台，可以是控制台、文件、界面的某个控件、远程服务器的套接字端口、Java消息服务、Windows NT的日志系统、远程UNIX服务器的Syslog日志系统。

录入笔也是可继承的，祖先的录入笔会继承到后代中。后代的记录员可以用继承来的录入笔和自身的录入笔同时将信息输出到多个数据源。

记录员的录入笔默认是可叠加的，可叠加是指的继承上的可叠加。如果禁止录入笔的叠加性，即禁掉了当前录入员继承祖先的录入笔，自身的录入笔还是会被后代继承的，被继承的录入笔也是可以同时使用的。

录入风格 录入风格顾名思义指的是记录信息的格式，每个录入笔可以指定一种专门的录入格式。

Git分支

Wed, 13 May 2015 00:00:00 +0000

几乎所有的VCS都支持分支的机制，到底什么是分支，有什么作用？

分支是一份完整的项目代码，一个项目可以有很多分支。多数VCS工具的分支机制很昂贵，需要完整的拷贝项目代码，对于代码量大的目录往往需要很长的时间。Git用快照加校验码的方式，让分支模型变得异常轻便，创建和切换分支都很快。Git的每个分支都是一些校验码构成的树或者图，要想理解Git的分支模型，请仔细阅读Branches in a Nutshell或者中文版何谓分支。

如何创建分支呢？

$ git branch testing

这种方式是在当前分支基础上创建了testing分支。首先应该明白，如果项目有多个分支，当前只有一个分支位于工作区域。一般一份代码至少有一个主干分支，叫做master。如果想指定从某个分支基础上创建分支只需要在后面再加上分支名字即可，例如

$ git branch testing master

就从master新建分支，不管当前处于哪个分支下。这个命令的执行不会将新建的分支testing切换到工作区域。

如何切换分支呢？

$ git checkout testing

或者可以在创建分支的时候执行

$ git checkout -b testing

表示创建新的分支testing并且切换过去。

是否在分支中新加的代码不会加在主干中？

是这样的。如果是在分支中做提交，那么只会影响分支，不会影响主干和其他的分支，可以保持主干的稳定性。

分支开发完后要怎么将代码加回主干？

$ git checkout?master

$ git merge testing

注意切换到master时需要保证所有记录的修改都应该已经提交，否则切换会失败。加回主干一般称作合并，合并的过程是在被提交的分支上生成一个新的提交，将两个分支的代码差异合并起来的操作。当同一个文件在两个分支上都有修改时就会产生冲突，需要手动解决。详细的冲突解决的示例可以参考Basic Merge Conflicts。

应该如何查看当前有哪些分支呢？

$ git branch

会显示所有分支的名字，更详细的信息可以加-v选项。还有两个选项也常用，–merged显示已合并到当前分支上的那些分支，–nomerged显示还未合并到当前分支上的那些分支。

分支合并后该怎么删除呢？

$ git branch -d <branch\_name>

之前提到的是否都是本地仓库的操作，本地的提交怎么会影响到远端呢，也需要合并吗？

对的，之前说的都是本地的操作，提交到远端也需要合并，但命令不太一样，原则上有些差别。

什么原则上的差别？

前面提到过向远程提交代码是一个推送操作，需要执行

$ git push

而能直接执行这个操作，需要当前分支跟踪着远端的某个分支。

$ git branch -vv

可以查询本地跟踪远程的那些分支情况。不管用推送去合并哪个分支都需要本地的分支跟踪远程的某个分支。如果是要推送一个远程不存在的分支，那么直接会在远程新建一个对应名字的分支，并被本地分支跟踪，命令是

$ git push <remote\_name> <branch\_name>

所以本地和远程的差别在于，远程使用推送去完成合并和创建新的分支。

远端的分支在本地名字好像都是类似origin/master的格式？

是的，origin是远端的名字，master是远端分支的名字。

前面好像有提过，从远程拉取代码使用fetch或者pull的命令，差别在哪里？

$ git fetch origin

会拉取所有在远端名为origin下的所有分支到本地，并且名字都叫origin/<branch_name>。这些拉取的分支是不能够直接切换和修改的，需要对它们用本地分支进行跟踪。如果本地已经有对应的跟踪分支，切换过去，直接进行合并，即执行

$ git checkout tracking_branch

$ git merge origin/tracking_branch

命令pull将fetch操作和merge操作一并执行。

如果本地没有跟踪分支，那么怎么新建一个呢？

$ git checkout -b branch_name remote_name/branch_name

这个命令看起来和本地新建一个分支好像没有差别？

看起来是没有差别，但会让新建的分支跟踪远端的分支。如果想要显式地执行跟踪，可以执行

$ git checkout --track remote_name/branch_name

如果要改变本地分支追踪的远程分支，可以执行

$ git checkout -u remote_name/branch_name

假如错误地推送给远程一个分支，怎么能够删除？

$ git push remote_name --delete branch_name

命令和选项都太多了，平常应该怎么用这些命令来做开发？

通常情况下，远端只会有一个分支，姑且叫做远端的主干分支。远端主干分支上的代码都是稳定的，经过测试，可以直接编译、执行、部署。本地开发时，需要有一个本地主干来跟踪远程的主干，因而这个主干通常不做开发，也一般都是稳定的。如果代码中有bug，那么从本地主干上切换出一个新的分支来做修改，修改完后再合并到主干，主干测试无误，推送到远端主干进行测试。如果代码要开发新的功能，也从主干上切换出一个新的分支来添加代码，添加完后，测试无误合并到主干，然后推送到主干进行测试。所以稳定的主干一般只有一个，不管是开发新功能还是修改漏洞都要在新分支上完成。

需要注意的一点是多人使用远端分支时候，主干推送可能会出错。这种情况发生在本地主干与远程的主干不同步，合作开发者已经将更新的提交推送到了远端，这时候需要本地主干同步后，再做本地的合并，然后再推送。

意思是说每次合并主干前，都执行一次$ git pull吗？

是的，最好这样。

之前有提到过$ git pull -r的操作，与上面有什么差别？

这个命令会以rebase的方式合并，而不是merge。

什么是rebase的方式？

假设在本地功能分支合并到主干分支的时候，忘记去同步远端主干到本地，这个时候直接执行$ git pull的话，可能会产生合并冲突，如果远端和本地的最新提交都修改了同一个文件的话。这种情况下，不仅需要手动合并，而且向远端提交分支的时候还后产生一个合并分支的分叉，提交历史看起来不太整齐。如果用rebase合并，Git会将本地合并的提交接在远端提交的后面，等价于先同步远端主干到本地，再去合并。

rebase可以单独使用吗？

可以的。rebase也能够用在本地功能分支向主干分支合并的时候。本地的主干可能有多个分支同时进行开发，也有可能同步了远程的主干，继续向前，所有头部的提交已经不再是当前功能分支切换时的情况了，这个时候rebase就很有用，直接在当前的功能分支下执行

$ git rebase master

能够让当前功能分支的新提交追加在主干新提交之后。另外值得提一句rebase操作的-i操作还能够在合并的时候修改提交历史，这个功能其实很好用，但也引起了很多的争议。

什么样的争议？

反对者的声音是提交历史记录了原本发生的历史，而历史不应该被改变，使用rebase等于在篡改历史，你相当于是在对过去说谎。支持者的声音是提交历史里应该记录的是项目如何被完成这个完整的故事，哪些保留，哪些删除，应该有所取舍，没有人会将一本书的草稿出版。

听起来挺有趣，那争议的结果怎样呢？

其实就是我们现在看到的，两种方式都保留在Git中。有一点建议是_只用rebase修改自己本地仓库的提交，千万不要修改本地之外的提交_（Do not rebase commits that exist outside your repository）。

这段文字改写自《Pro Git》一书的第二版第三章Branching部分。这里的改写仅用作回顾，不推荐直接学习，原书中有很多图示的说明更加直观。第二章请参考Git基础。

Git基础

Fri, 08 May 2015 00:00:00 +0000

如何开始用Git呢？

可以通过命令行和界面使用Git，但推荐命令行。掌握了命令行，界面也就基本掌握了，反之就不行。

如何创建一个Git仓库呢？

有两种方式：

第一种针对本地的某个项目，还未被Git记录过，那么cd到对应项目的根目录下，执行

$ git init

然后执行

$ git add *.c
$ git add LICENSE
$ git commit -m 'initial project version'

后面三句先不解释含义，后面会逐步说明。只说明第一句git init，表示在当前目录下，生成.git仓库来记录该目录下的项目。

第二种针对远端的某个项目，有对应项目的公开链接和权限，执行

$ git clone https://github.com/libgit2/libgit2

这句命令会在当前目录新建一个名为libgit2的目录，并在其中放置远端同步过来的项目。如果想让目录叫别的名字，执行

$ git clone https://github.com/libgit2/libgit2

会让目录叫mylibgit。

如何确定成功初始化了一个Git仓库呢？

进入对应项目跟目录下，执行

$ git status

如果返回On branch master之类的信息，则表明初始化成功。

如何开始用Git记录文件？

Git能够识别目录中的文件是已记录（tracked）还是未记录（untracked）。开始记录某个文件，需执行

$ git add <filename>

执行这句命令会将未记录的文件放入跟进区，文件变为已记录并且处于已跟进状态，等待被提交。

如何跟进已修改的文件？

如果一个已记录的文件被修改了，那么跟进的部分仍旧是未修改前的，要想让修改被跟进，那么也需要执行

$ git add <filename>

如何查看已记录文件的修改后未跟进与已跟进之间的差异？

执行

$ git diff

如何查看已记录文件已跟进部分与前一次提交文件之间的差异？

执行

$ git diff --staged

或者执行

$ git diff --cached

当执行git status时候，Git总把一些不相关的文件列在未记录的文件中，怎么样能够不看到这些文件，这些文件都不会被记录？

Git提供了配置忽略文件（Ignoring Files）的方法，即配置.gitignore文件。该文件的每一行为一项，#开头的行会被当作注释。一行一般被用来配置要屏蔽的某一类文件，语法上支持通配符。https://github.com/github/gitignore中有很多很好的例子可以做参考。配置好的.gitignore文件放在项目根目录下即可。

如何提交修改？

执行

$ git commit

会弹出编辑器让编辑提交的信息。或者直接用-m，即

$ git commit -m 'this is the message'

需要注意的是提交的修改都必须是已跟进的内容，如果想跳过跟进的步骤，直接加入-a选项，即

$ git commit -a -m 'this is the message'

不过需要明白的一点是，这句命令中被提交的都是已经有过记录的文件，如果是未记录文件，那么是无法提交的。

至此git init部分的后三句命令应该都清楚含义了。

如何删除一个文件呢？

可以执行

$ rm <filename>

这种方式仅会从磁盘上删除掉文件，但删除的操作并未被提交，还需要手动跟进提交一次。更容易的方法是执行

$ git rm <filename>

会直接删除文件并自动做跟进。

如果只是想不跟进这个文件，并不像从磁盘上删除该怎么办？

$ git rm --cached <filename>

怎么对跟进的文件重命名呢？

$ git mv <before_name> <after_name>

等价于执行

$ mv <before_name> <after_name>

$ git rm <before_name>

$ git add <after_name>

提交的流程已经清楚，但要想查看提交历史怎么办？

$ git log

?执行这条命令仅能够看到每次提交的校验码、作者、时间、修改的信息，怎么能够看到修改的概况？

$ git log --stat

这条命令确实可以看到每次提交删除和新增的概况，不过要看具体的差异怎么办？

$ git log -p

要是只想看最近两次的提交呢？

$ git log -2

提交历史虽然是按照时间的倒序排列的，但似乎无法知道各个提交之间的继承关系？

$ git log --graph

实际上git log还有查找特定字段--grep，自定义输出格式--pretty，显示单行--oneline等等一些更加复杂的命令，具体情况可参考Git的帮助手册。

有时候查看提交历史后才想起来，有些文件忘记提交了，想覆盖最后一次提交的历史怎么办？

$ git commit --amend

执行这句命令后，可以重新提交并覆盖最后一次的提交历史，实际上等了解了rebase后可以随意修改自己提交的历史。

有时候提交时错误跟进了一些文件，怎么样能够取消跟进？

$ git reset HEAD <file>

有时候想直接放弃某个文件的修改怎么办？

$ git checkout -- <file>

到目前似乎都只是在讲本地的一些操作，怎么样能够知道远端仓库的信息？

$ git remote

可以显示有哪些远端的分支

$ git remote -v

可以显示分支的具体URL，关于分支的概念，在Git分支中会有更详细的说明。

如果有多个远端仓库，怎么添加？

$ git remote add <branch_name> <url>

如何获取添加的远端分支的代码？

$ git fetch <branch_name>

这个操作，仅仅将远端代码同步到本地，不能编辑和修改，也不会自动并入到本地的任何一个分支。如果有某个本地分支在跟踪这个远程分支，直接切换到相应分支，执行

$ git pull

或者

$ git pull -r

-r表示以rebase的方式并入本地分支，主要是将远端的提交记录与本地的提交做次序上的先后调整。

如何将本地的代码推送到远端分支？

$ git push <remote_branch> <local_branch>

或者当前的分支跟踪了远程的分支，直接执行

$ git push

前面显示远端分支时候最多就是名字和URL，怎么显示更加详细的信息？

$ git remote show <remote_branch>

怎么对远端分支重命名？

$ git remote rename <old_name> <new_name>

怎么删除一个远端分支？

$ git remote rm <remote_branch>

打标签是记录软件里程碑的重要功能，Git是怎么支持这个特性的？

$ git tag

可以查看已经打过的标签。标签分含附注的标签和轻量级的标签，打含附注标签的命令是

$ git tag -a <tag_version> -m <tag_message>

打轻量级的标签的命令是

$ git tag <tag_version>

查看某个标签的具体情况的命令是

$ git show <tag_version>

以上打标签的方法都是针对最新一次提交，对历史的某次提交打标签，只需要指定上检验码就好了。另外这些标签在本地打完，并不会被push命令推送到远端，除非显式的指出

$ git push <remote_brach> <tag_version>

Git中有些命令似乎很长，但又用得很频繁，有没有办法可以简化？

Git提供了异名机制，可以自定义命令，例如

$ git config --global alias.co checkout
$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.st status
$ git config --global alias.unstage 'reset HEAD --'
$ git config --global alias.last 'log -1 HEAD'

这段文字改写自《Pro Git》一书的第二版第二章Basics部分。这里的改写仅用作回顾，不推荐直接学习，原书中有很多图示的说明更加直观。第一章请参考Git初识。