Posted on | In |

今天是大到暴雪，2015年第二场雪，天气预报这次准了，一直吵吵着要出去玩，下午和闺女就去颐和园玩了一圈，人可是真多啊，这么好的天，大家都舍不得在家呆着啊。还真不是很冷，很不错，玩的很开心。


Read more »

Posted on | In |

本次环境搭建说明：
Server是在CentOS 6.7
Client是在Win7
利用SSH

安装Git

在连网的情况下安装非常容易，一句yum install git搞定。

1
2
3
4
5
6
7
8
9
10
11
12
13
[root@Automation file]# yum install git
已加载插件：fastestmirror, refresh-packagekit, security
设置安装进程
base                                                     | 3.7 kB     00:00
base/primary_db                                          | 4.6 MB     00:08
extras                                                   | 3.4 kB     00:00
extras/primary_db                                        |  33 kB     00:00
updates                                                  | 3.4 kB     00:00
updates/primary_db                                       | 2.6 MB     00:02
包 git-1.7.1-3.el6_4.1.x86_64 已安装并且是最新版本
无须任何处理
[root@Automation file]# git version
git version 1.7.1

创建git用户

1
2
3
[root@Automation /]# useradd git
[root@Automation /]# su git
[git@Automation /]$
Read more »

Posted on | In |

一般我们总会有些文件无需纳入Git的管理，也不希望它们总出现在未跟踪文件列表。通常都是些自动生成的文件，比如日志文件，或者编译过程中创建的临时文件等。我们可以创建一个名为 .gitignore 的文件，列出要忽略的文件模式。

文件.gitignore的格式规范

  • 所有空行或者以注释符号 ＃ 开头的行都会被 Git 忽略。
  • 可以使用标准的 glob 模式匹配。
  • 匹配模式最后跟反斜杠（/）说明要忽略的是目录。
  • 要忽略指定模式以外的文件或目录，可以在模式前加上惊叹号（!）取反。

忽略文件的原则

  • 忽略操作系统自动生成的文件，比如缩略图等。
  • 忽略编译生成的中间文件、可执行文件等，比如Java编译产生的.class文件。
  • 忽略带有敏感信息的配置文件，比如存放口令的配置文件。

Note: 所有配置文件请参见：https://github.com/github/gitignore

Posted on | In |

有一个小技巧可以使你的Git体验更简单、容易、熟悉：别名。Git并不会在你输入部分命令时自动推断出你想要的命令。 如果不想每次都输入完整的Git命令，可以通过git config文件来轻松地为每一个命令设置一个别名。

1
2
3
4
$ 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 st rather than sit status。

有时候这种别名会非常有用和方便。例如，为了解决取消暂存文件的易用性问题，可以向 Git 中添加你自己的取消暂存别名：

1
$ git config --global alias.unstage 'reset HEAD --'

这会使下面的两个命令等价：

1
2
$ git unstage fileA
$ git reset HEAD -- fileA

通常也会添加一个 last 命令，像这样：

1
$ git config --global alias.last 'log -1 HEAD'

这样，可以轻松地看到最后一次提交：

1
2
3
4
5
6
7
8
9
10
11
12
$ git last
commit 40cddef63a739782e17e9f3da7ece29b9ec14a94
Author: yongfei.hu <huyongfei@huyongfei-pc.beyondsoft.com>
Date:   Tue Nov 17 10:21:02 2015 +0800

    3rd commit

commit adab21f28df71ab3850882fdad7f4c649fa79366
Author: yongfei.hu <huyongfei@huyongfei-pc.beyondsoft.com>
Date:   Tue Nov 17 10:20:42 2015 +0800

    2nd commit

Notes: 配置Git的时候，加上–global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。

Posted on | In |

算是对目前项目的一个工作总结吧。

现阶段总结

现在的项目，从框架的设计到现在的维护，已经接近3年的时间了。
团队主要分布于中国（北京和西安），美国和印度。我们是专职的自动化测试团队，做自动化的和做手工测试的严格分开，相对独立。手工测试熟悉业务逻辑，主要设计case。自动化测试主要把manual team提供的自动化case设计自动化脚本，并运行维护。

以下只是对本阶段的思考，项目主要是做GUI自动化测试，自动化team在实际的工作中，遇到的一些问题：

  • 不懂业务逻辑，写脚本的过程中或出现问题不能确定是不是bug，要和manual team确认。
    思考：automation team要不断学习业务逻辑，并且能站在用户角度考虑问题，设计合理的自动化用例和脚本。
  • 需求改变，case缺乏维护，自动化的case和脚本维护比较难。
    思考：需要经常和manual team沟通，定期更新case。
  • 自动化测试用例，按照手工Team给的用例来设计脚本，导致了功能检查点单一，脚本冗余，执行时间长等问题。
    思考： 自动化的测试用例，应该与传统的手工测试用例区分开来，E.g.,基于流程的自动化用例设计。
  • 框架的规范化，分布式团队，初期的时候还有规范，后来人员的扩充，造成了对象库，脚本等的冗余，命名的不统一等等。
    思考： 对规范进行重新思考和设计，要严格遵循，由团队Lead进行监督和Review。
  • 框架设计的过程中，也有一些小问题的存在，这里不做说明。
    思考： 重新考虑分层，对资源的引用，CI等等。
    Read more »

Posted on | In |

允许有意义的名称到一个特定的版本库中的标签操作。

前期准备

  1. 创建新文件“label.txt”，并提交三个版本。
  2. 查看状态
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    $ git log
    commit 40cddef63a739782e17e9f3da7ece29b9ec14a94
    Author: yongfei.hu <yongfeiuall@163.com>
    Date:   Tue Nov 17 10:21:02 2015 +0800

        3rd commit

    commit adab21f28df71ab3850882fdad7f4c649fa79366
    Author: yongfei.hu <yongfeiuall@163.com>
    Date:   Tue Nov 17 10:20:42 2015 +0800

        2nd commit

    commit eada2115194c8012be0db423d825d550f7102e09
    Author: yongfei.hu <yongfeiuall@163.com>
    Date:   Tue Nov 17 10:20:05 2015 +0800

        1st commit

创建标签

默认标签是打在最新提交的commit上的。

Read more »

Posted on | In |

在上节中，已经了解了基本的分支管理，在实际的项目中，肯定是存在远程仓库和团队协作的。下面就来重点讲解，在团队多人协作中的分支推送与抓取。

准备工作

  1. 在GitHub上创建新仓库”worktogether”，并添加文件”README.md”。
  2. Clone远程库到本地。 实际上Git自动把本地的master分支和远程的master分支对应起来了，且远程仓库的默认名称是origin。

查看远程

  • 查看

    1
    2
    $ git remote
    origin

  • 查看详细

    1
    2
    3
    $ git remote -v
    origin  https://github.com/yongfeiuall/worktogether.git (fetch)
    origin  https://github.com/yongfeiuall/worktogether.git (push)

分支推送

我们在远程仓库那章节已经学习了怎么使用。 详细请参考：远程仓库
修改”README.md”，并提交，推送。

1
2
3
4
5
6
$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 286 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/yongfeiuall/worktogether.git
   952b8b0..242264d  master -> master

Push Result

分支抓取

团队协作时，在PUSH时难免会有冲突的出现，我们主要是看一下这个处理流程。

另一人推送提交

  1. 在另一台电脑clone仓库”worktogether。
  2. 修改文件，并提交。
  3. Push到远程
    1
    2
    3
    4
    5
    6
    7
    8
    $ git push origin master
    Counting objects: 3, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (2/2), done.
    Writing objects: 100% (3/3), 307 bytes | 0 bytes/s, done.
    Total 3 (delta 0), reused 0 (delta 0)
    To https://github.com/yongfeiuall/worktogether.git
       242264d..5b7966c  master -> master

你操作同一个文件

  1. 修改文件，并提交

  2. Push到远程

    1
    2
    3
    4
    5
    6
    7
    8
    9
    $ git push origin master
    To https://github.com/yongfeiuall/worktogether.git
     ! [rejected]        master -> master (fetch first)
    error: failed to push some refs to 'https://github.com/yongfeiuall/worktogether.git'
    hint: Updates were rejected because the remote contains work that you do
    hint: not have locally. This is usually caused by another repository pushing
    hint: to the same ref. You may want to first integrate the remote changes
    hint: (e.g., 'git pull ...') before pushing again.
    hint: See the 'Note about fast-forwards' in 'git push --help' for details.

    推送失败，因为另一个人的最新提交和你试图推送的提交有冲突。

  3. get最新的提交

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    $ git pull
    remote: Counting objects: 3, done.
    remote: Compressing objects: 100% (2/2), done.
    remote: Total 3 (delta 0), reused 3 (delta 0), pack-reused 0
    Unpacking objects: 100% (3/3), done.
    From https://github.com/yongfeiuall/worktogether
       242264d..5b7966c  master     -> origin/master
    Auto-merging README.md
    CONFLICT (content): Merge conflict in README.md
    Automatic merge failed; fix conflicts and then commit the result.

  4. 手动解决冲突，并提交

  5. 再次Push
    1
    2
    3
    4
    5
    6
    7
    8
    $ git push origin master
    Counting objects: 6, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (4/4), done.
    Writing objects: 100% (6/6), 564 bytes | 0 bytes/s, done.
    Total 6 (delta 1), reused 0 (delta 0)
    To https://github.com/yongfeiuall/worktogether.git
       5b7966c..1d2aaa5  master -> master

引用LIAOXUEFENG BLOG

多人协作的工作模式通常是这样：

  1. 首先，可以试图用git push origin branch-name推送自己的修改；
  2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
  3. 如果合并有冲突，则解决冲突，并在本地提交；
  4. 没有冲突或者解决掉冲突后，再用git push origin branch-name推送就能成功！
    如果git pull提示“no tracking information”，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream branch-name origin/branch-name。

Posted on | In |

在实际开发中，一般企业中开发一个项目的分支策略:

主分支(master)

Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。
代码库应该有一个、且仅有一个主分支。
master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活。

开发分支(develop)

主分支只用来分布重大版本，日常开发都是在这个分支上完成。
到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本。

功能分支(feature)

它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。
每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。

预发布分支(release)

预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。预发布分支是从Develop分支上面 分出来的，预发布结束以后，必须合并进Develop和Master分支。

bug分支(fix bug)

软件正式发布以后，难免会出现bug。有了bug就需要修复，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

如果当前分支的工作还未完成，bug又急于修改，那该怎么办呢？

  1. 创建文件‘bug.txt’，并提交

  2. 创建新分支

    1
    2
    $ git checkout -b develop
    Switched to a new branch 'develop'

  3. 修改文件，并查看状态

    1
    2
    3
    4
    5
    6
    7
    8
    9
    $ git status
    On branch develop
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git checkout -- <file>..." to discard changes in working directory)

            modified:   bug.txt

    no changes added to commit (use "git add" and/or "git commit -a")

    此时需要修改一个紧急的bug。我们可以利用stash功能，把当前工作现场“储藏”起来，修改完bug后再恢复现场后继续工作。

  4. 保存现场

    1
    2
    3
    $ git stash
    Saved working directory and index state WIP on develop: 3978a2e add bug.txt
    HEAD is now at 3978a2e add bug.txt

  5. 再查看工作区状态

    1
    2
    3
    $ git status
    On branch develop
    nothing to commit, working directory clean

    工作区是干净的，就可以创建bug分支进行修改bug。

  6. 修改bug完成后，切换到之前的‘develop’分支

  7. 查看保存现场

    1
    2
    $ git stash list
    stash@{0}: WIP on develop: 3978a2e add bug.txt

  8. 恢复现场

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    $ git stash pop
    On branch develop
    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git checkout -- <file>..." to discard changes in working directory)

            modified:   bug.txt

    no changes added to commit (use "git add" and/or "git commit -a")
    Dropped refs/stash@{0} (ea54fb954976da63842dcdd7faab12092ae71130)

Notes:

  • 你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

    1
    $ git stash apply stash@{0}

  • 用git stash apply恢复后，stash内容并不删除，你需要用git stash drop来删除；

其它分支

在Git中，由于分支是如此的强大，所以大家可以根据需要创建即可。