版本管理

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。 Git的标签虽然是版本库的快照，但其实它就是指向某个commit的指针（跟分支很像对不对？但是分支可以移动，标签不能移动），所以，创建和删除标签都是瞬间完成的。 在Git中打标签非常简单，首先，切换到需要打标签的分支上： $ git branch * dev master $ git checkout master Switched to branch 'master' 然后，敲命令 git tag <name> 就可以打一个新标签： $ git tag v1.0 可以用命令 git tag 查看所有标签： $ git tag v1.0 默认标签是打在最新提交的commit上的。有时候，如果忘了打标签，比如，现在已经是周五了，但应该在周一打的标签没有打，怎么办？ 方法是找到历史提交的commit id，然后打上就可以了： $ git log --pretty=oneline --abbrev-commit 6a5819e merged bug fix 101 cc17032 fix bug 101 7825a50 merge with no-ff 6224937 add merge

Git Git 是目前世界上最先进的分布式版本控制系统（没有之一） 作用 源代码管理 为什么要进行源代码管理? 方便多人协同开发 方便版本控制 Git单人本地仓库操作 安装git 　　sudo apt-get install git 查看git版本 　　git --version 新建本地仓库 　　git init 配置个人信息 　　git config user.name 'lgc' 　　git config user.email '1399569097@qq.com' 查看文件状态 　　git status 将工作区文件添加到暂存区 　　git add . 　　　　 将项目文件添加到暂存区 　　git add login.py 将指定文件添加到暂存区 将暂存区文件添加到本地仓库 　　git commit -m '版本描述' 查看历史版本 　　git log 　　git reflog 回退版本 强制覆盖暂存区和工作区的文件 回退到当前版本的前一个版本 　　git reset --hard HEAD^ 回退到指定版本 　　git reset --hard 版本号 回退版本 只覆盖暂存区的文件 回退到当前版本的前一个版本 　　git reset HEAD^ 回退到制定版本 　　git reset 版本号 删除文件 ---确认删除处理 　　1，删除文件 　　　　rm 文件名 　　2

一、实验目的 (1)了解分布式分布式版本控制系统的核心机理； (2)熟练掌握git的基本指令和分支管理指令； 二、实验内容 (1)安装git (2)初始配胥git，git init git status指令 (3)掌握git log ,git add ,git diff指令 (4)掌握git tag git branch, git commit指令 (5)掌握git revert指令 三、实验记录 1 .初始配置 Git # 设置你的 Git 用户名 git config --global user.name "<Your-Full-Name>" # 设置你的 Git 邮箱 git config --global user.email "<your-email-address>" # 确保 Git 输出内容带有颜色标记 git config --global color.ui auto # 对比显示原始状态 git config --global merge.conflictstyle diff3 git config --list （ 该处操作在输入用户名和邮箱时漏掉空格，后面操作已解决 ） 2.从头创建仓库 （1）创建项目目录 、 git init 、克隆 创建一个目录se2020-git-course，在该目录中创建另一个目录 new-git-project，使用 cd

1 总览 git 的分支整体预览图如下： 从上图可以看到主要包含下面几个分支： master：git默认主分支（这里不作操作）。 stable：稳定分支，替代master，主要用来版本发布。 develop：日常开发分支，该分支正常保存了开发的最新代码。 feature：具体的功能开发分支，只与 develop 分支交互。 release：release 分支可以认为是 stable分支的未测试版。比如说某一期的功能全部开发完成，那么就将 develop 分支合并到 release分支，测试没有问题并且到了发布日期就合并到 stable分支，进行发布。 bugfix：线上 bug 修复分支。 1.1 主分支 因为master分支我们不作操作，所以针对stable和develop这两个主分支来讲解。 stable分支：用来发布，管理着多个稳定的版本。 develop分支：就是我们日常开发的分支。 使用这两个分支就具有了最简单的开发模式：develop 分支用来开发功能，开发完成并且测试没有问题后，则将 develop 分支的代码合并到 stable分支并发布。 在开发中如果我们只用主分支来进行管理，那么就会造成develop发布完成之后才能进行下一迭代的开发，开发会比较缓慢。如果线上代码发现bug之后，很难进行bug修复。 针对以上问题，建立辅助分支就能完美的解决。 1.2 辅助分支

1. 你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？ 场景： 程序员果冻正在对几个文件进行修改，实现一个大的功能， 这时候，程序员小飞也要改其中一个文件，快速修复一个问题。怎么办？ 一个代码文件被签出 (check out) 之后，另一个团队成员可以签出这个文件，并修改，然后签入么？ 有几种设计，各有什么优缺点？ 例如，签出文件后，此文件就加锁，别人无法签出； 或者， 所有人都可以自由签出文件 回答问题：我们团队的代码在github上，用的是windows系统。我们团队的在处理文件的锁定问题没有加锁，我们的项目比不上大型企业的项目，所以没有对文件迁入迁出进行过多的限制。将文件在迁入迁出时加锁，显然可以保证源代码修改的同步性，减少不必要的冲突和错误，但是这样的缺点是显而易见的，由于缺乏了并行性，项目开发的效率就被极大地降低了，以我们小组现在的项目规模就不需要加锁。 回答场景：主分支master,若要实现一个大的功能，可以在当前master分支开一个新的分支用户对文件进行改写。下一个人也开在当前master分支开一个分支新的用户分支进行bug的修复，修复完成之后与master进行合并，完成了功能的实现之后再与master分支进行合并。 2. 如何看到这个文件和之前版本的差异？ 如何看到代码修改和工作项 （work item），缺陷修复 （bug fix) 的关系。

小组名称： 飞天小女警 项目名称： 礼物挑选小工具 小组成员： 沈柏杉（组长）、程媛媛、杨钰宁、谭力铭 0. 如果你的团队来了一个新队员，有一台全新的机器，你们是否有一个文档，只要设置了相应的权限，她就可以根据文档，从头开始搭建环境， 并成功地把最新、最稳定版本的软件编译出来，并运行必要的单元测试？（在这过程中，不需要和老队员做任何交流） 答 ：团队在初期编译了一篇文档，供组员或其他成员搭建环境，如果有需要可以向组长索取。 1. 你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？场景：程序员果冻正在对几个文件进行修改，实现一个大的功能， 这时候，程序员小飞也要改其中一个文件，快速修复一个问题。怎么办？一个代码文件被签出 (check out) 之后，另一个团队成员可以签出这个文件，并修改，然后签入么？有几种设计，各有什么优缺点？例如，签出文件后，此文件就加锁，别人无法签出；或者，所有人都可以自由签出文件 我们用git控制代码版本。 让个人根据自己的i情况处理，当其影响到整个团队时，就尽量严格，因为整个团队都可能会受影响，同时提高可预见性，公开显示固定的构建时间对于该问题中的场景描述，是否会造成损失要具体问题具体分析，有的时候宽一些更适宜，有的时候严一些比较没有损失，于是我们根据构建执法的宽严表来进行工作，当团队成员的行为只是影响到个人时，就尽量宽松

问题来自于： 现代软件工程讲义 源代码管理 0. 在吹牛之前，先回答这个问题： 如果你的团队来了一个新队员，有一台全新的机器， 你们是否有一个文档，只要设置了相应的权限 ，她就可以根据文档，从头开始搭建环境，并成功地把最新、最稳定版本的软件编译出来，并运行必要的单元测试？ （在这过程中，不需要和老队员做任何交流） 在团队的资料库的根目录中，会有一个"开发快速上手指南.docx"这个文档，这个文档作为一个索引文档，提供了资料库里面所有相关文档/工具的索引地址，格式可以多种多样，我提供一种格式作为参考： 开发工具以及配置： jdk: svn://xxx.xxxx.xxxx /jdk-7u80-windows-i586.zip eclipse: svn://xxx.xxxx.xxxx /eclipse-jee-luna-SR1a-win32.zip Tomcat: svn://xxx.xxxx.xxxx /apache-tomcat-7.0.55.zip MySQL: svn://xxx.xxxx.xxxx /mysql-5.5.47-win32.zip 部署详细步骤： 新建文件夹workspace 打开eclipse File à Switch Workspace à Other... à Browse..., 选择workspace这个目录，点击Ok，切换至新的工作空间

源代码管理的10 个实践问题： 0. 在吹牛之前，先回答这个问题： 如果你的团队来了一个新队员，有一台全新的机器， 你们是否有一个文档，只要设置了相应的权限 ，她就可以根据文档，从头开始搭建环境，并成功地把最新、最稳定版本的软件编译出来，并运行必要的单元测试？ （在这过程中，不需要和老队员做任何交流） 答：我们团队目前没有做专门的文档让新成员熟悉并搭建环境，最初的时候并没有太在意说团队要换人加入新成员，这次加入新成员，他们对整个项目的了解是通过软件规格说明书和老成员的讲解进行的，回头来看看这个问题，还真的值得我们反思，确实需要一篇这样的文档，节省时间。 1. 你的团队的源代码控制在哪里？用的是什么系统？ 如何处理文件的锁定问题？ 场景： 程序员果冻 正在对几个文件进行修改，实现一个大的功能， 这时候， 程序员小飞 也要改其中一个文件，快速修复一个问题。怎么办？ 一个代码文件被签出 (check out) 之后，另一个团队成员可以签出这个文件，并修改，然后签入么？ 有几种设计，各有什么优缺点？ 例如，签出文件后，此文件就加锁，别人无法签出； 或者， 所有人都可以自由签出文件 答：我们团队的源代码是通过码市coding.net托管的，里面有我们的团队项目，每个成员都在里面，每个人都有一个自己的账号，只要登陆就能看的到项目动态，其中还有任务分配。我们的项目是公开的

0、在吹牛之前，先回答这个问题： 如果你的团队来了一个新队员，有一台全新的机器， 你们是否有一个文档，只要设置了相应的权限，她就可以根据文档，从头开始搭建环境，并成功地把最新、最稳定版本的软件编译出来，并运行必要的单元测试？ （在这过程中，不需要和老队员做任何交流） 将代码传到coding上。 1、你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？ 所有人都可以自由的签出源代码。 场景： 程序员果冻正在对几个文件进行修改，实现一个大的功能， 这时候，程序员小飞也要改其中一个文件，快速修复一个问题。怎么办？一个代码文件被签出 (check out) 之后，另一个团队成员可以签出这个文件，并修改，然后签入么？有几种设计，各有什么优缺点？ 设计一：签出文件后，此文件就加锁，别人无法签出；优点：多人修改一个代码不会发生冲撞，缺点：锁定后别人无法再修改代码。 设计二：所有人都可以自由签出文件；优点：所有人都将可以对代码进行修改，提高效率，缺点：可能导致代码的编写流程混乱，发生冲撞。 2. 如何看到这个文件和之前版本的差异？ 如何看到代码修改和工作项 （work item），缺陷修复 （bug fix) 的关系。 场景： 程序员果冻看到某个文件被修改了，他怎么看到这个文件在最近的修改究竟改了哪些地方？ 场景： 程序员果冻看到某个文件在最新版本被改动了100 多行

0. 在吹牛之前，先回答这个问题： 如果你的团队来了一个新队员，有一台全新的机器， 你们是否有一个文档，只要设置了相应的权限，她就可以根据文档，从头开始搭建环境，并成功地把最新、最稳定版本的软件编译出来，并运行必要的单元测试？ （在这过程中，不需要和老队员做任何交流） 答：来了新队员的话，确实需要这样一个文档，队友可以根据文档从头开始了解软件并且无需和老队员交流。不过我们现有的也就是需求规格说明书供新队员阅读并且了解团队的任务。 如下图： 1. 你的团队的源代码控制在哪里？用的是什么系统？如何处理文件的锁定问题？ 场景： 程序员果冻正在对几个文件进行修改，实现一个大的功能， 这时候，程序员小飞也要改其中一个文件，快速修复一个问题。怎么办？ 一个代码文件被签出 (check out) 之后，另一个团队成员可以签出这个文件，并修改，然后签入么？ 有几种设计，各有什么优缺点？ 例如，签出文件后，此文件就加锁，别人无法签出； 或者， 所有人都可以自由签出文件 答：我们的项目在git上托管，采用git的方式进行版本控制，这个是我们在开发开始时就达成的共识，针对这种多人多任务的开发模式，我们认为git是再好不过的选择，于是我们从开发到现在一直采用这种方式。 2. 如何看到这个文件和之前版本的差异？ 如何看到代码修改和工作项 （work item），缺陷修复 （bug fix) 的关系。 场景：