发布新日志

  • git的功能介绍

    2016-04-08 11:20:20

    Git的功能特性:
    从一般开发者的角度来看,git有以下功能:
    1、从服务器上克隆数据库(包括代码和版本信息)到单机上。
    2、在自己的机器上创建分支,修改代码。
    3、在单机上自己创建的分支上提交代码。
    4、在单机上合并分支。
    5、新建一个分支,把服务器上最新版的代码fetch下来,然后跟自己的主分支合并。
    6、生成补丁(patch),把补丁发送给主开发者。
    7、看主开发者的反馈,如果主开发者发现两个一般开发者之间有冲突(他们之间可以合作解决的冲突),就会要求他们先解决冲突,然后再由其中一个人提交。如果主开发者可以自己解决,或者没有冲突,就通过。
    8、一般开发者之间解决冲突的方法,开发者之间可以使用pull 命令解决冲突,解决完冲突之后再向主开发者提交补丁。
    功能介绍:
    从主开发者的角度(假设主开发者不用开发代码)看,git有以下功能:
    1:查看邮件或者通过其它方式查看一般开发者的提交状态。
    2:打上补丁,解决冲突(可以自己解决,也可以要求开发者之间解决以后再重新提交,如果是开源项目,还要决定哪些补丁有用,哪些不用)。
    3:向公共服务器提交结果,然后通知所有开发人员。
    优点:
    适合分布式开发,强调个体。
    公共服务器压力和数据量都不会太大。
    速度快、灵活。
    任意两个开发者之间可以很容易的解决冲突。
    离线工作。
    缺点:
    资料少(起码中文资料很少)。
    学习周期相对而言比较长。
    不符合常规思维。
    代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
    开发模式
    尽管 git 是一个正式项目发布系统,它却可以方便地将你的项目建立在松散的开发人员组织形式上。 Linux内核的开发,就是按这样的模式进行的。在 Randy Dunlap 的著作中("Merge to Mainline" 第17页)就有很好的介绍
    需要强调的是真正的非常规的开发组织形式,git 这种组织形式,意味着对于工作流程的约束,没有任何强迫性的原则。你不必从唯一一个远程版本库中导入(工作目录)。
    项目领导人(project lead)的工作推介
    1.在你自己的本地机器上准备好主版本库。你的所有工作都在这里完成。
    2.准备一个能让大家访问的公共版本库。
    如果其他人是通过默协议的方式(http)来导入版本库的,那么你有必要保持这个 默协议的友好性。 git-init-db 之后,复制自标准模板库的 $GIT_DIR/hooks/post-update 将包含一个对 git-update-server-info 的调用,但是 post-update 默认是不能唤起它自身的。通过 chmod +x post-update 命令使能它。这样让 git-update-server-info 保证那些必要的文件是最新的。
    3.将你的主版本库推入公共版本库。
    4.git-repack 公共版本库。这将建立一个包含初始化提交对象集的打包作为项目的起始线,可能的话,执行一下 git-prune,要是你的公共库是通过 pull 操作来从你打包过的版本库中导入的。
    5.在你的主版本库中开展工作,这些工作可能是你自己的最项目的编辑,可能是你由 email 收到的一个补丁,也可能是你从这个项目的“子系统负责人” 的公共库中导入的工作等等。
    你可以在任何你喜欢的时候重新打包你的这个私人的版本库。
    6.将项目的进度推入公共库中,并给大家公布一下。
    7.尽管一段时间以后,"git-repack" 公共库。并回到第5步继续工作。
    项目的子系统负责人(subsystem maintainer)也有自己的公共库,工作流程大致如下:
    1.准备一个你自己的工作目录,它通过 git-clone 克隆自项目领导人的公共库。原始的克隆地址(URL)将被保存在 .git/remotes/origin 中。
    2.准备一个可以给大家访问的公共库,就像项目领导人所做的那样。
    3.复制项目领导人的公共库中的打包文件到你的公共库中,除非你的公共库和项目领导人的公共库是在同一部主机上。以后你就可以通过 objects/info/alternates 文件的指向来浏览它所指向的版本库了。
    4.将你的主版本库推入你的公共版本库,并运行 git-repack,如果你的公共库是通过的公共库是通过 pull 来导入的数据的话,再执行一下 git-prune 。
    5.在你的主版本库中开展工作。这些工作可能包括你自己的编辑,来自 email 的补丁,从项目领导人,“下一级子项目负责人”的公共库哪里导入的工作等等。
    你可以在任何时候重新打包你的私人版本库。
    6.将你的变更推入公共库中,并且请“项目领导人”和“下级子系统负责人”导入这些变更。
    7. 每隔一段时间之后,git-repack 公共库。回到第 5 步继续工作。
    “一般开发人员”无须自己的公共库,大致的工作方式是:
    1.准备你的工作库,它应该用 git-clone 克隆自“项目领导人”的公共库(如果你只是开发子项目,那么就克隆“子项目负责人”的)。克隆的源地址(URL)会被保存到 .git/remotes/origin 中。
    2.在你的个人版本库中的 master 分支中开展工作。
    3.每隔一段时间,向上游的版本库运行一下 git-fetch origin 。这样只会做 git-pull 一半的操作,即只克隆不合并。公共版本库的新的头就会被保存到 .git/refs/heads/origins 。
    4.用 git-cherry origin 命令,看一下你有什么补丁被接纳了。并用 git-rebase origin 命令将你以往的变更迁移到最新的上游版本库的状态中。(关于 git-rebase 命令,请参考 git-rebase)
    5.用 git-format-patch origin 生成 email 形式的补丁并发给上游的维护者。回到第二步接着工作。

  • git的基本常用命令2

    2016-04-08 11:15:32

    git push –u(第一次要用-u 以后不需要) origin master 把当前master分支推送到远程库
    git clone https://github.com/tugenhua0707/testgit  从远程库中克隆
    git checkout –b dev  创建dev分支 并切换到dev分支上
    git branch  查看当前所有的分支
    git checkout master 切换回master分支
    git merge dev    在当前的分支上合并dev分支
    git branch –d dev 删除dev分支
    git branch name  创建分支
    git stash 把当前的工作隐藏起来 等以后恢复现场后继续工作
    git stash list 查看所有被隐藏的文件列表
    git stash apply 恢复被隐藏的文件,但是内容不删除
    git stash drop 删除文件
    git stash pop 恢复文件的同时 也删除文件
    git remote 查看远程库的信息
    git remote –v 查看远程库的详细信息
    git push origin master  Git会把master分支推送到远程库对应的远程分支上
  • git的基本常用命令1

    2016-04-08 10:12:21

    mkdir: xx(创建一个空目录,xx指目录名)
    pwd: 显示当前目录的路径
    git init: 把当前的目录变成可以管理的git仓库,生成隐藏.git文件
    git add xx:把xx文件添加到暂存区去
    git commit: -m“XX”:提交文件 -m后面的是注释
    git status: 查看仓库状态
    git diff xx:查看xx文件修改了哪些内容
    git log: 查看历史记录
    git reset --hard HEAD 或者git reset --hard HEAD~ 回退到上一个版本
    (如果想回退到100个版本,使用git reset -hard HEAD~100)
           
    cat XX :查看XX文件内容
    git reflog: 查看历史记录的版本号id
    git checkout -- XX :把XX文件在工作区的修改全部撤销
    git rm XX:删除XX文件
    git remote add origin https://github.com/tugenhua0707/testgit关联一个远程库
    git push -u(第一次要用-u,以后不需要)origin master把当前master

  • git功能介绍

    2016-04-08 10:09:31

    Git的功能特性:
    从一般开发者的角度来看,git有以下功能:
    1、从服务器上克隆数据库(包括代码和版本信息)到单机上。
    2、在自己的机器上创建分支,修改代码。
    3、在单机上自己创建的分支上提交代码。
    4、在单机上合并分支。
    5、新建一个分支,把服务器上最新版的代码fetch下来,然后跟自己的主分支合并。
    6、生成补丁(patch),把补丁发送给主开发者。
    7、看主开发者的反馈,如果主开发者发现两个一般开发者之间有冲突(他们之间可以合作解决的冲突),就会要求他们先解决冲突,然后再由其中一个人提交。如果主开发者可以自己解决,或者没有冲突,就通过。
    8、一般开发者之间解决冲突的方法,开发者之间可以使用pull 命令解决冲突,解决完冲突之后再向主开发者提交补丁。
    功能介绍:
    从主开发者的角度(假设主开发者不用开发代码)看,git有以下功能:
    1:查看邮件或者通过其它方式查看一般开发者的提交状态。
    2:打上补丁,解决冲突(可以自己解决,也可以要求开发者之间解决以后再重新提交,如果是开源项目,还要决定哪些补丁有用,哪些不用)。
    3:向公共服务器提交结果,然后通知所有开发人员。
    优点:
    适合分布式开发,强调个体。
    公共服务器压力和数据量都不会太大。
    速度快、灵活。
    任意两个开发者之间可以很容易的解决冲突。
    离线工作。
    缺点:
    资料少(起码中文资料很少)。
    学习周期相对而言比较长。
    不符合常规思维。
    代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
    开发模式
    尽管 git 是一个正式项目发布系统,它却可以方便地将你的项目建立在松散的开发人员组织形式上。 Linux内核的开发,就是按这样的模式进行的。在 Randy Dunlap 的著作中("Merge to Mainline" 第17页)就有很好的介绍
    需要强调的是真正的非常规的开发组织形式,git 这种组织形式,意味着对于工作流程的约束,没有任何强迫性的原则。你不必从唯一一个远程版本库中导入(工作目录)。
    项目领导人(project lead)的工作推介
    1.在你自己的本地机器上准备好主版本库。你的所有工作都在这里完成。
    2.准备一个能让大家访问的公共版本库。
    如果其他人是通过默协议的方式(http)来导入版本库的,那么你有必要保持这个 默协议的友好性。 git-init-db 之后,复制自标准模板库的 $GIT_DIR/hooks/post-update 将包含一个对 git-update-server-info 的调用,但是 post-update 默认是不能唤起它自身的。通过 chmod +x post-update 命令使能它。这样让 git-update-server-info 保证那些必要的文件是最新的。
    3.将你的主版本库推入公共版本库。
    4.git-repack 公共版本库。这将建立一个包含初始化提交对象集的打包作为项目的起始线,可能的话,执行一下 git-prune,要是你的公共库是通过 pull 操作来从你打包过的版本库中导入的。
    5.在你的主版本库中开展工作,这些工作可能是你自己的最项目的编辑,可能是你由 email 收到的一个补丁,也可能是你从这个项目的“子系统负责人” 的公共库中导入的工作等等。
    你可以在任何你喜欢的时候重新打包你的这个私人的版本库。
    6.将项目的进度推入公共库中,并给大家公布一下。
    7.尽管一段时间以后,"git-repack" 公共库。并回到第5步继续工作。
    项目的子系统负责人(subsystem maintainer)也有自己的公共库,工作流程大致如下:
    1.准备一个你自己的工作目录,它通过 git-clone 克隆自项目领导人的公共库。原始的克隆地址(URL)将被保存在 .git/remotes/origin 中。
    2.准备一个可以给大家访问的公共库,就像项目领导人所做的那样。
    3.复制项目领导人的公共库中的打包文件到你的公共库中,除非你的公共库和项目领导人的公共库是在同一部主机上。以后你就可以通过 objects/info/alternates 文件的指向来浏览它所指向的版本库了。
    4.将你的主版本库推入你的公共版本库,并运行 git-repack,如果你的公共库是通过的公共库是通过 pull 来导入的数据的话,再执行一下 git-prune 。
    5.在你的主版本库中开展工作。这些工作可能包括你自己的编辑,来自 email 的补丁,从项目领导人,“下一级子项目负责人”的公共库哪里导入的工作等等。
    你可以在任何时候重新打包你的私人版本库。
    6.将你的变更推入公共库中,并且请“项目领导人”和“下级子系统负责人”导入这些变更。
    7. 每隔一段时间之后,git-repack 公共库。回到第 5 步继续工作。
    “一般开发人员”无须自己的公共库,大致的工作方式是:
    1.准备你的工作库,它应该用 git-clone 克隆自“项目领导人”的公共库(如果你只是开发子项目,那么就克隆“子项目负责人”的)。克隆的源地址(URL)会被保存到 .git/remotes/origin 中。
    2.在你的个人版本库中的 master 分支中开展工作。
    3.每隔一段时间,向上游的版本库运行一下 git-fetch origin 。这样只会做 git-pull 一半的操作,即只克隆不合并。公共版本库的新的头就会被保存到 .git/refs/heads/origins 。
    4.用 git-cherry origin 命令,看一下你有什么补丁被接纳了。并用 git-rebase origin 命令将你以往的变更迁移到最新的上游版本库的状态中。(关于 git-rebase 命令,请参考 git-rebase)
    5.用 git-format-patch origin 生成 email 形式的补丁并发给上游的维护者。回到第二步接着工作。
  • git的功能介绍

    2016-04-08 10:04:40

    Git的功能特性:
    从一般开发者的角度来看,git有以下功能:
    1、从服务器上克隆数据库(包括代码和版本信息)到单机上。
    2、在自己的机器上创建分支,修改代码。
    3、在单机上自己创建的分支上提交代码。
    4、在单机上合并分支。
    5、新建一个分支,把服务器上最新版的代码fetch下来,然后跟自己的主分支合并。
    6、生成补丁(patch),把补丁发送给主开发者。
    7、看主开发者的反馈,如果主开发者发现两个一般开发者之间有冲突(他们之间可以合作解决的冲突),就会要求他们先解决冲突,然后再由其中一个人提交。如果主开发者可以自己解决,或者没有冲突,就通过。
    8、一般开发者之间解决冲突的方法,开发者之间可以使用pull 命令解决冲突,解决完冲突之后再向主开发者提交补丁。
    功能介绍:
    从主开发者的角度(假设主开发者不用开发代码)看,git有以下功能:
    1:查看邮件或者通过其它方式查看一般开发者的提交状态。
    2:打上补丁,解决冲突(可以自己解决,也可以要求开发者之间解决以后再重新提交,如果是开源项目,还要决定哪些补丁有用,哪些不用)。
    3:向公共服务器提交结果,然后通知所有开发人员。
    优点:
    适合分布式开发,强调个体。
    公共服务器压力和数据量都不会太大。
    速度快、灵活。
    任意两个开发者之间可以很容易的解决冲突。
    离线工作。
    缺点:
    资料少(起码中文资料很少)。
    学习周期相对而言比较长。
    不符合常规思维。
    代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
    开发模式
    尽管 git 是一个正式项目发布系统,它却可以方便地将你的项目建立在松散的开发人员组织形式上。 Linux内核的开发,就是按这样的模式进行的。在 Randy Dunlap 的著作中("Merge to Mainline" 第17页)就有很好的介绍
    需要强调的是真正的非常规的开发组织形式,git 这种组织形式,意味着对于工作流程的约束,没有任何强迫性的原则。你不必从唯一一个远程版本库中导入(工作目录)。
    项目领导人(project lead)的工作推介
    1.在你自己的本地机器上准备好主版本库。你的所有工作都在这里完成。
    2.准备一个能让大家访问的公共版本库。
    如果其他人是通过默协议的方式(http)来导入版本库的,那么你有必要保持这个 默协议的友好性。 git-init-db 之后,复制自标准模板库的 $GIT_DIR/hooks/post-update 将包含一个对 git-update-server-info 的调用,但是 post-update 默认是不能唤起它自身的。通过 chmod +x post-update 命令使能它。这样让 git-update-server-info 保证那些必要的文件是最新的。
    3.将你的主版本库推入公共版本库。
    4.git-repack 公共版本库。这将建立一个包含初始化提交对象集的打包作为项目的起始线,可能的话,执行一下 git-prune,要是你的公共库是通过 pull 操作来从你打包过的版本库中导入的。
    5.在你的主版本库中开展工作,这些工作可能是你自己的最项目的编辑,可能是你由 email 收到的一个补丁,也可能是你从这个项目的“子系统负责人” 的公共库中导入的工作等等。
    你可以在任何你喜欢的时候重新打包你的这个私人的版本库。
    6.将项目的进度推入公共库中,并给大家公布一下。
    7.尽管一段时间以后,"git-repack" 公共库。并回到第5步继续工作。
    项目的子系统负责人(subsystem maintainer)也有自己的公共库,工作流程大致如下:
    1.准备一个你自己的工作目录,它通过 git-clone 克隆自项目领导人的公共库。原始的克隆地址(URL)将被保存在 .git/remotes/origin 中。
    2.准备一个可以给大家访问的公共库,就像项目领导人所做的那样。
    3.复制项目领导人的公共库中的打包文件到你的公共库中,除非你的公共库和项目领导人的公共库是在同一部主机上。以后你就可以通过 objects/info/alternates 文件的指向来浏览它所指向的版本库了。
    4.将你的主版本库推入你的公共版本库,并运行 git-repack,如果你的公共库是通过的公共库是通过 pull 来导入的数据的话,再执行一下 git-prune 。
    5.在你的主版本库中开展工作。这些工作可能包括你自己的编辑,来自 email 的补丁,从项目领导人,“下一级子项目负责人”的公共库哪里导入的工作等等。
    你可以在任何时候重新打包你的私人版本库。
    6.将你的变更推入公共库中,并且请“项目领导人”和“下级子系统负责人”导入这些变更。
    7. 每隔一段时间之后,git-repack 公共库。回到第 5 步继续工作。
    “一般开发人员”无须自己的公共库,大致的工作方式是:
    1.准备你的工作库,它应该用 git-clone 克隆自“项目领导人”的公共库(如果你只是开发子项目,那么就克隆“子项目负责人”的)。克隆的源地址(URL)会被保存到 .git/remotes/origin 中。
    2.在你的个人版本库中的 master 分支中开展工作。
    3.每隔一段时间,向上游的版本库运行一下 git-fetch origin 。这样只会做 git-pull 一半的操作,即只克隆不合并。公共版本库的新的头就会被保存到 .git/refs/heads/origins 。
    4.用 git-cherry origin 命令,看一下你有什么补丁被接纳了。并用 git-rebase origin 命令将你以往的变更迁移到最新的上游版本库的状态中。(关于 git-rebase 命令,请参考 git-rebase)
    5.用 git-format-patch origin 生成 email 形式的补丁并发给上游的维护者。回到第二步接着工作。
  • git的功能介绍

    2016-04-08 09:59:52

    Git的功能特性:

    从一般开发者的角度来看,git有以下功能:

    1:从服务器上克隆数据库(包括代码和版本信息)到单机上。

    2:在自己的机器上创建分支,修改代码。

    3:在单机上自己创建的分支上提交代码。

    4:在单机上合并分支。

    5:新建一个分支,把服务器上最新版的代码fetch下来,然后跟自己的主分支合并。

    6:生成补丁(patch),把补丁发送给主开发者。

    7:看主开发者的反馈,如果主开发者发现两个一般开发者之间有冲突(他们之间可以合作解决的冲突),就会要求他们先解决冲突,然后再由其中一个人提交。如果主开发者可以自己解决,或者没有冲突,就通过。

    8:一般开发者之间解决冲突的方法,开发者之间可以使用pull 命令解决冲突,解决完冲突之后再向主开发者提交补丁。

    功能介绍:

    从主开发者的角度(假设主开发者不用开发代码)看,git有以下功能:

    1:查看邮件或者通过其它方式查看一般开发者的提交状态。

    2:打上补丁,解决冲突(可以自己解决,也可以要求开发者之间解决以后再重新提交,如果是开源项目,还要决定哪些补丁有用,哪些不用)。

    3:向公共服务器提交结果,然后通知所有开发人员。

    优点:

    适合分布式开发,强调个体。

    公共服务器压力和数据量都不会太大。

    速度快、灵活。

    任意两个开发者之间可以很容易的解决冲突。

    离线工作

    缺点:

    资料少(起码中文资料很少)。

    学习周期相对而言比较长。

    不符合常规思维。

    代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

    开发模式

    尽管 git 是一个正式项目发布系统,它却可以方便地将你的项目建立在松散的开发人员组织形式上。 Linux内核的开发,就是按这样的模式进行的。在 Randy Dunlap 的著作中("Merge to Mainline" 17页)就有很好的介绍

    需要强调的是真正的非常规的开发组织形式, git 这种组织形式,意味着对于工作流程的约束,没有任何强迫性的原则。你不必从唯一一个远程版本库中导入(工作目录)。

    项目领导人(project lead)的工作推介

    1. 在你自己的本地机器上准备好主版本库。你的所有工作都在这里完成。

    2. 准备一个能让大家访问的公共版本库。

    如果其他人是通过默协议的方式(http)来导入版本库的,那么你有必要保持这个 默协议的友好性。 git-init-db 之后,复制自标准模板库的 $GIT_DIR/hooks/post-update 将包含一个对 git-update-server-info 的调用,但是 post-update 默认是不能唤起它自身的。通过 chmod +x post-update 命令使能它。这样让 git-update-server-info 保证那些必要的文件是最新的。

    3. 将你的主版本库推入公共版本库。

    4. git-repack 公共版本库。这将建立一个包含初始化提交对象集的打包作为项目的起始线,可能的话,执行一下 git-prune,要是你的公共库是通过 pull 操作来从你打包过的版本库中导入的。

    5. 在你的主版本库中开展工作,这些工作可能是你自己的最项目的编辑,可能是你由 email 收到的一个补丁,也可能是你从这个项目的子系统负责人的公共库中导入的工作等等。

    你可以在任何你喜欢的时候重新打包你的这个私人的版本库。

    6. 将项目的进度推入公共库中,并给大家公布一下。

    7. 尽管一段时间以后,"git-repack" 公共库。并回到第5步继续工作。

    项目的子系统负责人(subsystem maintainer)也有自己的公共库,工作流程大致如下:

    1. 准备一个你自己的工作目录,它通过 git-clone 克隆自项目领导人的公共库。原始的克隆地址(URL)将被保存在 .git/remotes/origin 中。

    2. 准备一个可以给大家访问的公共库,就像项目领导人所做的那样。

    3. 复制项目领导人的公共库中的打包文件到你的公共库中,除非你的公共库和项目领导人的公共库是在同一部主机上。以后你就可以通过 objects/info/alternates 文件的指向来浏览它所指向的版本库了。

    4. 将你的主版本库推入你的公共版本库,并运行 git-repack,如果你的公共库是通过的公共库是通过 pull 来导入的数据的话,再执行一下 git-prune

    5. 在你的主版本库中开展工作。这些工作可能包括你自己的编辑,来自 email 的补丁,从项目领导人,下一级子项目负责人的公共库哪里导入的工作等等。

    你可以在任何时候重新打包你的私人版本库。

    6.将你的变更推入公共库中,并且请项目领导人下级子系统负责人导入这些变更。

    7. 每隔一段时间之后,git-repack 公共库。回到第 5 步继续工作。

    一般开发人员无须自己的公共库,大致的工作方式是:

    1. 准备你的工作库,它应该用 git-clone 克隆自项目领导人的公共库(如果你只是开发子项目,那么就克隆子项目负责人的)。克隆的源地址(URL)会被保存到 .git/remotes/origin 中。

    2. 在你的个人版本库中的 master 分支中开展工作。

    3. 每隔一段时间,向上游的版本库运行一下 git-fetch origin 。这样只会做 git-pull 一半的操作,即只克隆不合并。公共版本库的新的头就会被保存到 .git/refs/heads/origins

    4. 用 git-cherry origin 命令,看一下你有什么补丁被接纳了。并用 git-rebase origin 命令将你以往的变更迁移到最新的上游版本库的状态中。(关于 git-rebase 命令,请参考 git-rebase

    5. git-format-patch origin 生成 email 形式的补丁并发给上游的维护者。回到第二步接着工作。

  • git初认识

    2016-04-08 09:38:07

    什么是Git?

    Git是一款免费、开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目。Git的读音为/gɪt/。

    Git是一个开源的分布式版本控制系统,用以有效、高速的处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理liunx内核开发而开发的一个开放源码的版本控制软件。

    Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper,后者之前一直是 Linux 内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得 BitKeeper 的许可证并不适合开放源码社区的工作,因此 Torvalds 决定着手研究许可证更为灵活的版本控制系统。尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程,但是我们已经发现在很多其他自由软件项目中也使用了 Git。例如 最近就迁移到 Git 上来了,很多 Freedesktop 的项目也迁移到了 Git 上

  • git初接触之一

    2016-04-08 09:23:42

    什么是Git?

    Git是一款免费、开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目。Git的读音为/gɪt/。

    Git是一个开源的分布式版本控制系统,用以有效、高速的处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

    Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper,后者之前一直是 Linux 内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得 BitKeeper 的许可证并不适合开放源码社区的工作,因此 Torvalds 决定着手研究许可证更为灵活的版本控制系统。尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程,但是我们已经发现在很多其他自由软件项目中也使用了 Git。例如 最近就迁移到 Git 上来了,很多 Freedesktop 的项目也迁移到了 Git 上。


    产品特点

    分布式和集中式的最大区别在于开发者可以本地提交。每个开发者机器上都有一个服务器的数据库

    下图是经典的git开发过程。

    Git的功能特性:

    从一般开发者的角度来看,git有以下功能:

    1:从服务器上克隆数据库(包括代码和版本信息)到单机上。

    2:在自己的机器上创建分支,修改代码。

    3:在单机上自己创建的分支上提交代码。

    4:在单机上合并分支。

    5:新建一个分支,把服务器上最新版的代码fetch下来,然后跟自己的主分支合并。

    6:生成补丁(patch),把补丁发送给主开发者。

    7:看主开发者的反馈,如果主开发者发现两个一般开发者之间有冲突(他们之间可以合作解决的冲突),就会要求他们先解决冲突,然后再由其中一个人提交。如果主开发者可以自己解决,或者没有冲突,就通过。

    8:一般开发者之间解决冲突的方法,开发者之间可以使用pull 命令解决冲突,解决完冲突之后再向主开发者提交补丁。

    功能介绍

    从主开发者的角度(假设主开发者不用开发代码)看,git有以下功能:

    1:查看邮件或者通过其它方式查看一般开发者的提交状态。

    2:打上补丁,解决冲突(可以自己解决,也可以要求开发者之间解决以后再重新提交,如果是开源项目,还要决定哪些补丁有用,哪些不用)。

    3:向公共服务器提交结果,然后通知所有开发人员。

    优点:

    适合分布式开发,强调个体。

    公共服务器压力和数据量都不会太大。

    速度快、灵活。

    任意两个开发者之间可以很容易的解决冲突。

    离线工作。

    缺点:

    资料少(起码中文资料很少)。

    学习周期相对而言比较长。

    不符合常规思维。

    代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

    开发模式

    尽管 git 是一个正式项目发布系统,它却可以方便地将你的项目建立在松散的开发人员组织形式上。 Linux内核的开发,就是按这样的模式进行的。在 Randy Dunlap 的著作中("Merge to Mainline" 第17页)就有很好的介绍

    需要强调的是真正的非常规的开发组织形式, git 这种组织形式,意味着对于工作流程的约束,没有任何强迫性的原则。你不必从唯一一个远程版本库中导入(工作目录)。

    项目领导人(project lead)的工作推介

    1. 在你自己的本地机器上准备好主版本库。你的所有工作都在这里完成。

    2. 准备一个能让大家访问的公共版本库。

    如果其他人是通过默协议的方式(http)来导入版本库的,那么你有必要保持这个 默协议的友好性。 git-init-db 之后,复制自标准模板库的 $GIT_DIR/hooks/post-update 将包含一个对 git-update-server-info 的调用,但是 post-update 默认是不能唤起它自身的。通过 chmod +x post-update 命令使能它。这样让 git-update-server-info 保证那些必要的文件是最新的。

    3. 将你的主版本库推入公共版本库。

    4. git-repack 公共版本库。这将建立一个包含初始化提交对象集的打包作为项目的起始线,可能的话,执行一下 git-prune,要是你的公共库是通过 pull 操作来从你打包过的版本库中导入的。

    5. 在你的主版本库中开展工作,这些工作可能是你自己的最项目的编辑,可能是你由 email 收到的一个补丁,也可能是你从这个项目的“子系统负责人” 的公共库中导入的工作等等。

    你可以在任何你喜欢的时候重新打包你的这个私人的版本库。

    6. 将项目的进度推入公共库中,并给大家公布一下。

    7. 尽管一段时间以后,"git-repack" 公共库。并回到第5步继续工作。

    项目的子系统负责人(subsystem maintainer)也有自己的公共库,工作流程大致如下:

    1. 准备一个你自己的工作目录,它通过 git-clone 克隆自项目领导人的公共库。原始的克隆地址(URL)将被保存在 .git/remotes/origin 中。

    2. 准备一个可以给大家访问的公共库,就像项目领导人所做的那样。

    3. 复制项目领导人的公共库中的打包文件到你的公共库中,除非你的公共库和项目领导人的公共库是在同一部主机上。以后你就可以通过 objects/info/alternates 文件的指向来浏览它所指向的版本库了。

    4. 将你的主版本库推入你的公共版本库,并运行 git-repack,如果你的公共库是通过的公共库是通过 pull 来导入的数据的话,再执行一下 git-prune 。

    5. 在你的主版本库中开展工作。这些工作可能包括你自己的编辑,来自 email 的补丁,从项目领导人,“下一级子项目负责人”的公共库哪里导入的工作等等。

    你可以在任何时候重新打包你的私人版本库。

    6. 将你的变更推入公共库中,并且请“项目领导人”和“下级子系统负责人”导入这些变更。

    7. 每隔一段时间之后,git-repack 公共库。回到第 5 步继续工作。

    “一般开发人员”无须自己的公共库,大致的工作方式是:

    1. 准备你的工作库,它应该用 git-clone 克隆自“项目领导人”的公共库(如果你只是开发子项目,那么就克隆“子项目负责人”的)。克隆的源地址(URL)会被保存到 .git/remotes/origin 中。

    2. 在你的个人版本库中的 master 分支中开展工作。

    3. 每隔一段时间,向上游的版本库运行一下 git-fetch origin 。这样只会做 git-pull 一半的操作,即只克隆不合并。公共版本库的新的头就会被保存到 .git/refs/heads/origins 。

    4. 用 git-cherry origin 命令,看一下你有什么补丁被接纳了。并用 git-rebase origin 命令将你以往的变更迁移到最新的上游版本库的状态中。(关于 git-rebase 命令,请参考 git-rebase)

    5. 用 git-format-patch origin 生成 email 形式的补丁并发给上游的维护者。回到第二步接着工作。

  • git初接触之一

    2016-04-07 17:54:40

      
    什么是Git?

    Git是一款免费、开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目。Git的读音为/gɪt/。

    Git是一个开源的分布式版本控制系统,用以有效、高速的处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

    Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper,后者之前一直是 Linux 内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得 BitKeeper 的许可证并不适合开放源码社区的工作,因此 Torvalds 决定着手研究许可证更为灵活的版本控制系统。尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程,但是我们已经发现在很多其他自由软件项目中也使用了 Git。例如 最近就迁移到 Git 上来了,很多 Freedesktop 的项目也迁移到了 Git 上。


    产品特点

    分布式和集中式的最大区别在于开发者可以本地提交。每个开发者机器上都有一个服务器的数据库。

    下图是经典的git开发过程。

    Git的功能特性:

    从一般开发者的角度来看,git有以下功能:

    1:从服务器上克隆数据库(包括代码和版本信息)到单机上。

    2:在自己的机器上创建分支,修改代码。

    3:在单机上自己创建的分支上提交代码。

    4:在单机上合并分支。

    5:新建一个分支,把服务器上最新版的代码fetch下来,然后跟自己的主分支合并。

    6:生成补丁(patch),把补丁发送给主开发者。

    7:看主开发者的反馈,如果主开发者发现两个一般开发者之间有冲突(他们之间可以合作解决的冲突),就会要求他们先解决冲突,然后再由其中一个人提交。如果主开发者可以自己解决,或者没有冲突,就通过。

    8:一般开发者之间解决冲突的方法,开发者之间可以使用pull 命令解决冲突,解决完冲突之后再向主开发者提交补丁。

    功能介绍

    从主开发者的角度(假设主开发者不用开发代码)看,git有以下功能:

    1:查看邮件或者通过其它方式查看一般开发者的提交状态。

    2:打上补丁,解决冲突(可以自己解决,也可以要求开发者之间解决以后再重新提交,如果是开源项目,还要决定哪些补丁有用,哪些不用)。

    3:向公共服务器提交结果,然后通知所有开发人员。

    优点:

    适合分布式开发,强调个体。

    公共服务器压力和数据量都不会太大。

    速度快、灵活。

    任意两个开发者之间可以很容易的解决冲突。

    离线工作。

    缺点:

    资料少(起码中文资料很少)。

    学习周期相对而言比较长。

    不符合常规思维。

    代码保密性差,一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

    开发模式

    尽管 git 是一个正式项目发布系统,它却可以方便地将你的项目建立在松散的开发人员组织形式上。 Linux内核的开发,就是按这样的模式进行的。在 Randy Dunlap 的著作中("Merge to Mainline" 第17页)就有很好的介绍

    需要强调的是真正的非常规的开发组织形式, git 这种组织形式,意味着对于工作流程的约束,没有任何强迫性的原则。你不必从唯一一个远程版本库中导入(工作目录)。

    项目领导人(project lead)的工作推介

    1. 在你自己的本地上准备好主版本库。你的所有工作都在这里完成。

    2. 准备一个能让大家访问的公共版本库。

    如果其他人是通过默协议的方式(http)来导入版本库的,那么你有必要保持这个 默协议的友好性。 git-init-db 之后,复制自标准模板库的 $GIT_DIR/hooks/post-update 将包含一个对 git-update-server-info 的调用,但是 post-update 默认是不能唤起它自身的。通过 chmod +x post-update 命令使能它。这样让 git-update-server-info 保证那些必要的文件是最新的。

    3. 将你的主版本库推入公共版本库。

    4. git-repack 公共版本库。这将建立一个包含初始化提交对象集的打包作为项目的起始线,可能的话,执行一下 git-prune,要是你的公共库是通过 pull 操作来从你打包过的版本库中导入的。

    5. 在你的主版本库中开展工作,这些工作可能是你自己的最项目的编辑,可能是你由 email 收到的一个补丁,也可能是你从这个项目的“子系统负责人” 的公共库中导入的工作等等。

    你可以在任何你喜欢的时候重新打包你的这个私人的版本库。

    6. 将项目的进度推入公共库中,并给大家公布一下。

    7. 尽管一段时间以后,"git-repack" 公共库。并回到第5步继续工作。

    项目的子系统负责人(subsystem maintainer)也有自己的公共库,工作流程大致如下:

    1. 准备一个你自己的工作目录,它通过 git-clone 克隆自项目领导人的公共库。原始的克隆地址(URL)将被保存在 .git/remotes/origin 中。

    2. 准备一个可以给大家访问的公共库,就像项目领导人所做的那样。

    3. 复制项目领导人的公共库中的打包文件到你的公共库中,除非你的公共库和项目领导人的公共库是在同一部主机上。以后你就可以通过 objects/info/alternates 文件的指向来浏览它所指向的版本库了。

    4. 将你的主版本库推入你的公共版本库,并运行 git-repack,如果你的公共库是通过的公共库是通过 pull 来导入的数据的话,再执行一下 git-prune 。

    5. 在你的主版本库中开展工作。这些工作可能包括你自己的编辑,来自 email 的补丁,从项目领导人,“下一级子项目负责人”的公共库哪里导入的工作等等。

    你可以在任何时候重新打包你的私人版本库。

    6. 将你的变更推入公共库中,并且请“项目领导人”和“下级子系统负责人”导入这些变更。

    7. 每隔一段时间之后,git-repack 公共库。回到第 5 步继续工作。

    “一般开发人员”无须自己的公共库,大致的工作方式是:

    1. 准备你的工作库,它应该用 git-clone 克隆自“项目领导人”的公共库(如果你只是开发子项目,那么就克隆“子项目负责人”的)。克隆的源地址(URL)会被保存到 .git/remotes/origin 中。

    2. 在你的个人版本库中的 master 分支中开展工作。

    3. 每隔一段时间,向上游的版本库运行一下 git-fetch origin 。这样只会做 git-pull 一半的操作,即只克隆不合并。公共版本库的新的头就会被保存到 .git/refs/heads/origins 。

    4. 用 git-cherry origin 命令,看一下你有什么补丁被接纳了。并用 git-rebase origin 命令将你以往的变更迁移到最新的上游版本库的状态中。(关于 git-rebase 命令,请参考 git-rebase)

    5. 用 git-format-patch origin 生成 email 形式的补丁并发给上游的维护者。回到第二步接着工作。

Open Toolbar