模式一:
Git作为一个正式项目发布系统,它能够极其有效的组织松散的开发人员,是一种非常规的开发组织形式,对工作流程没有任何强迫性的约束,比较灵活。
项目领导人
1.在自己本地机器上创建主版本库,并在此进行所有工作。
2.准备一个能让大家访问的公共版本库。
3.将你的主版本库推入公共版本库。
4.git-repack 公共版本库。这将建立一个包含初始化提交对象集的打包作为项目的起始线。
5.在你的主版本库中开展工作,包括自己的工作、收到的邮件补丁、“子系统负责人” 的公共库中导入的工作等等。
6.将项目的进度推入公共库中,并给大家公布一下。
* 7.尽管一段时间以后,"git-repack" 公共库。并回到第5步继续工作。
项目的子系统负责人
1.新建一个你自己的工作目录,通过 git-clone 克隆项目领导人的公共库。
2.准备一个可以给大家访问的公共库,就像项目领导人所做的那样。
3.复制项目领导人的公共库中的打包文件到你的公共库中。
4.将你的主版本库推入你的公共版本库,并运行 git-repack,如果你的公共库是通过的公共库是通过pull来导入的数据的话,再执行一下git-prune。
5.在你的主版本库中开展工作。这些工作包括自己的工作、收到的邮件补丁、“下一级子项目负责人”的公共库中导入的工作等等。
6.将你的变更推入公共库中,并且请“项目领导人”和“下级子系统负责人”导入这些变更。
* 7.每隔一段时间之后,git-repack 公共库。回到第 5 步继续工作。
一般开发人员
1.通过git-clone克隆“项目领导人”的公共库,作为自己的工作库。
2.在你的个人版本库中的 master 分支中开展工作。
3.每隔一段时间,向上游的版本库运行一下 git-fetch origin 。这样只会做 git-pull 一半的操作,即只克隆不合并。
4.用 git-cherry origin 命令,看一下你有什么补丁被接纳了。并用 git-rebase origin 命令将你以往的变更迁移到最新的上游版本库的状态中。
5.用git-format-patch origin生成email形式的补丁并发给上游的维护者。回到第二步接着工作。
模式二:
利用服务器进行协同开发工作(代码管理模式探讨)
一个团队进行项目开发,必须要有清晰的开发交互管理模式。一般来讲,一个团队总是要用一个服务器来做为代码的存储和下载中心。如何将基于分布式概念的git用活成为一个方便的团队版本管理工具,是一个值得研究的问题。下面以一个实例来探讨一下:
现有A,B,C,D四个员工,一台服务器。服务器IP为172.16.1.50,A的计算机IP为172.16.1.51,B的计算机IP为 172.16.1.52,C的计算机IP为172.16.1.53,D的计算机IP为172.16.1.54。有一个项目,名叫GOD,A是管理员。可以有如下几种工作方式。
一: A在本地机器上建立GOD的代码库。其他三位员工直接从A的机器上克隆(利用SSH,需要知道用户和密码)代码和版本信息。然后,B,C,D分别在各自的 master分支里进行工作。等到要提交的时候,比如说B要提交,则B给A发封邮件,提醒一下,我这儿有些工作要提交给你。A收到提示后,就主动去B的机器(通过SSH)上去取(需要知道用户名,密码)master分支,取的时候,将取回的版本信息存放到本地的一个新的分支中去。然后,再将这个新的分支与自己的工作分支(可能是master分支)进行合并,产生新的代码。合并完成后,再通知B,我已经合并完成了,请你同步到最新的代码来。于是,B用 git-fetch或git-pull将A的合并后的代码同步到本地机器上来。这样就完成了一个交互。C,D也类似。
这样做的特点就是:
1. 没有使用独立的服务器;
2. 需要B,C,D和A知道互相知道对方的机器帐号,密码;
3. 不需使用邮件来交互;
4. 需要管理员A来主动取各个员工的代码。
二: A在服务器上建立一个GOD的公开版本库。利用git协议,或http协议(匿名的)。A在本机上工作的内容,首先是推到服务器上去(git- push)。其它员工,从服务器上去克隆(git-clone)代码。B,C,D在下载代码后,在各自的master分支上开发。B做了一些工作后,再提醒A来我这里取代码,A主动去取。取回后,再合并。最后,把合并好的代码再Push到服务器上去。其他员工从服务器上来pull代码,进行同步更新。这样做的特点是:
1. 使用了独立的服务器;
2. 需要A知道B,C,D的机器帐号,密码。不需要B,C,D知道A的机器帐号,密码;
3. 不需使用邮件来交互;
4. 需要管理员A来主动取各个员工的代码。
三: A在服务器上建立一个GOD的公开版本库。利用git协议,或http协议(匿名的)。A在本机上工作的内容,首先是推到服务器上去(git- push)。其它员工,从服务器上去克隆(git-clone)代码。B,C,D在下载代码后,在各自的master分支上开发。B做了一些工作后,利用 git-format-patch origin 打自己的版本与origin版本的补丁(最好在打补丁之前运行一下git-fetch origin,跟进的最新的版本记录),生成后,通过Email的形式,将补丁发给A。A收到后,对自已的工作代码打补丁。最后,把打补丁(合并)好的代码再Push到服务器上去。其他员工从服务器上来pull代码,进行同步更新。这样做的特点是:
1. 使用了独立的服务器;
2. 不需要A知道B,C,D的机器帐号,密码。不需要B,C,D知道A的机器帐号,密码。只需要知道各自的邮箱即可。
3. 需使用邮件来交互;
4. 不需要管理员A来主动取各个员工的代码。由员工主动向管理员发送补丁文件。
Git作为一个正式项目发布系统,它能够极其有效的组织松散的开发人员,是一种非常规的开发组织形式,对工作流程没有任何强迫性的约束,比较灵活。
项目领导人
1.在自己本地机器上创建主版本库,并在此进行所有工作。
2.准备一个能让大家访问的公共版本库。
3.将你的主版本库推入公共版本库。
4.git-repack 公共版本库。这将建立一个包含初始化提交对象集的打包作为项目的起始线。
5.在你的主版本库中开展工作,包括自己的工作、收到的邮件补丁、“子系统负责人” 的公共库中导入的工作等等。
6.将项目的进度推入公共库中,并给大家公布一下。
* 7.尽管一段时间以后,"git-repack" 公共库。并回到第5步继续工作。
项目的子系统负责人
1.新建一个你自己的工作目录,通过 git-clone 克隆项目领导人的公共库。
2.准备一个可以给大家访问的公共库,就像项目领导人所做的那样。
3.复制项目领导人的公共库中的打包文件到你的公共库中。
4.将你的主版本库推入你的公共版本库,并运行 git-repack,如果你的公共库是通过的公共库是通过pull来导入的数据的话,再执行一下git-prune。
5.在你的主版本库中开展工作。这些工作包括自己的工作、收到的邮件补丁、“下一级子项目负责人”的公共库中导入的工作等等。
6.将你的变更推入公共库中,并且请“项目领导人”和“下级子系统负责人”导入这些变更。
* 7.每隔一段时间之后,git-repack 公共库。回到第 5 步继续工作。
一般开发人员
1.通过git-clone克隆“项目领导人”的公共库,作为自己的工作库。
2.在你的个人版本库中的 master 分支中开展工作。
3.每隔一段时间,向上游的版本库运行一下 git-fetch origin 。这样只会做 git-pull 一半的操作,即只克隆不合并。
4.用 git-cherry origin 命令,看一下你有什么补丁被接纳了。并用 git-rebase origin 命令将你以往的变更迁移到最新的上游版本库的状态中。
5.用git-format-patch origin生成email形式的补丁并发给上游的维护者。回到第二步接着工作。
模式二:
利用服务器进行协同开发工作(代码管理模式探讨)
一个团队进行项目开发,必须要有清晰的开发交互管理模式。一般来讲,一个团队总是要用一个服务器来做为代码的存储和下载中心。如何将基于分布式概念的git用活成为一个方便的团队版本管理工具,是一个值得研究的问题。下面以一个实例来探讨一下:
现有A,B,C,D四个员工,一台服务器。服务器IP为172.16.1.50,A的计算机IP为172.16.1.51,B的计算机IP为 172.16.1.52,C的计算机IP为172.16.1.53,D的计算机IP为172.16.1.54。有一个项目,名叫GOD,A是管理员。可以有如下几种工作方式。
一: A在本地机器上建立GOD的代码库。其他三位员工直接从A的机器上克隆(利用SSH,需要知道用户和密码)代码和版本信息。然后,B,C,D分别在各自的 master分支里进行工作。等到要提交的时候,比如说B要提交,则B给A发封邮件,提醒一下,我这儿有些工作要提交给你。A收到提示后,就主动去B的机器(通过SSH)上去取(需要知道用户名,密码)master分支,取的时候,将取回的版本信息存放到本地的一个新的分支中去。然后,再将这个新的分支与自己的工作分支(可能是master分支)进行合并,产生新的代码。合并完成后,再通知B,我已经合并完成了,请你同步到最新的代码来。于是,B用 git-fetch或git-pull将A的合并后的代码同步到本地机器上来。这样就完成了一个交互。C,D也类似。
这样做的特点就是:
1. 没有使用独立的服务器;
2. 需要B,C,D和A知道互相知道对方的机器帐号,密码;
3. 不需使用邮件来交互;
4. 需要管理员A来主动取各个员工的代码。
二: A在服务器上建立一个GOD的公开版本库。利用git协议,或http协议(匿名的)。A在本机上工作的内容,首先是推到服务器上去(git- push)。其它员工,从服务器上去克隆(git-clone)代码。B,C,D在下载代码后,在各自的master分支上开发。B做了一些工作后,再提醒A来我这里取代码,A主动去取。取回后,再合并。最后,把合并好的代码再Push到服务器上去。其他员工从服务器上来pull代码,进行同步更新。这样做的特点是:
1. 使用了独立的服务器;
2. 需要A知道B,C,D的机器帐号,密码。不需要B,C,D知道A的机器帐号,密码;
3. 不需使用邮件来交互;
4. 需要管理员A来主动取各个员工的代码。
三: A在服务器上建立一个GOD的公开版本库。利用git协议,或http协议(匿名的)。A在本机上工作的内容,首先是推到服务器上去(git- push)。其它员工,从服务器上去克隆(git-clone)代码。B,C,D在下载代码后,在各自的master分支上开发。B做了一些工作后,利用 git-format-patch origin 打自己的版本与origin版本的补丁(最好在打补丁之前运行一下git-fetch origin,跟进的最新的版本记录),生成后,通过Email的形式,将补丁发给A。A收到后,对自已的工作代码打补丁。最后,把打补丁(合并)好的代码再Push到服务器上去。其他员工从服务器上来pull代码,进行同步更新。这样做的特点是:
1. 使用了独立的服务器;
2. 不需要A知道B,C,D的机器帐号,密码。不需要B,C,D知道A的机器帐号,密码。只需要知道各自的邮箱即可。
3. 需使用邮件来交互;
4. 不需要管理员A来主动取各个员工的代码。由员工主动向管理员发送补丁文件。