GIT的工程管理和简单使用
软件工程项目管理入门教程
软件工程项目管理入门教程第一章：软件工程项目管理概述1.1 软件工程项目管理的定义软件工程项目管理是指对软件开发项目的规划、组织、协调和控制，以确保项目能够按时、按质、按量地交付，并满足用户需求和预期目标。
1.2 软件工程项目管理的重要性软件工程项目管理的重要性在于确保项目的成功交付，有效管理资源和风险，提高项目的质量和效率。
它能够帮助项目团队增强协作能力，提高沟通效率，降低项目失败风险。
1.3 软件工程项目管理的基本原理软件工程项目管理的基本原理包括项目目标明确、需求变更管理、计划和进度管理、团队协作、质量管理和风险管理等。
第二章：软件工程项目管理流程2.1 项目启动阶段项目启动阶段是确定项目目标和范围，明确项目可行性，并启动项目组织和资源准备工作的阶段。
2.2 项目规划阶段项目规划阶段是制定详细的项目计划和进度安排，确定项目资源和风险管理策略，以及定义项目团队的组织结构和角色职责的阶段。
2.3 项目执行阶段项目执行阶段是按照项目计划进行工作的阶段，包括需求分析、系统设计、编码、测试、部署等活动，并进行项目进度和质量的监控和控制。
2.4 项目收尾阶段项目收尾阶段是项目的总结和交付阶段，包括项目验收、用户培训、文档归档、项目经验总结等活动。
第三章：软件工程项目管理工具3.1 项目管理软件项目管理软件是指用于辅助项目管理的计划、进度、资源和风险管理的工具，常用的有Microsoft Project、JIRA、Redmine等。
3.2 版本控制工具版本控制工具是用于管理软件开发过程中的代码版本和变更，确保项目代码的一致性和可追溯性，常用的有Git、SVN等。
3.3 缺陷管理工具缺陷管理工具用于跟踪和管理软件开发过程中的缺陷和问题，提供问题报告、分配和解决的功能，常用的有Bugzilla、JIRA等。
3.4 团队协作工具团队协作工具用于促进项目团队之间的交流和协作，提供在线文档编辑、讨论、任务分配等功能，常用的有Microsoft Teams、Slack等。
工程项目管理版本控制方法
摘要：在工程项目管理中，版本控制是确保项目文档、数据和信息的一致性和可追溯性的关键手段。
本文旨在探讨工程项目管理中常用的版本控制方法，分析其优缺点，并提出相应的实施策略，以帮助项目管理者提高项目效率，降低风险。
一、引言随着工程项目规模的不断扩大和复杂性的增加，项目文档、数据和信息的管理变得越来越重要。
版本控制作为一种有效的管理手段，可以帮助项目团队跟踪项目进展，确保信息的一致性和准确性。
本文将重点介绍工程项目管理中常用的版本控制方法，分析其应用场景和实施策略。
二、版本控制方法概述1. 文件版本控制文件版本控制是最常见的版本控制方法，主要用于跟踪文件的变化和修改。
它包括以下几种形式：（1）本地文件版本控制：通过在本地计算机上建立文件版本，实现对文件修改的跟踪。
这种方法简单易行，但存在数据安全风险和协作困难。
（2）网络文件版本控制：通过将文件存储在网络服务器上，实现多人协同编辑和版本控制。
常见的网络文件版本控制系统有Git、Subversion等。
2. 数据库版本控制数据库版本控制主要用于跟踪数据库结构、数据内容的变化。
它包括以下几种形式：（1）数据库备份：定期对数据库进行备份，以便在数据丢失或损坏时恢复。
这种方法简单易行，但无法实现实时跟踪和版本控制。
（2）数据库版本管理系统：通过数据库版本管理系统（如PostgreSQL的pglogical）实现对数据库结构和数据的版本控制。
3. 流程版本控制流程版本控制主要用于跟踪项目流程的变化。
它包括以下几种形式：（1）流程图版本控制：通过绘制流程图，记录项目流程的变化。
这种方法直观易懂，但难以实现自动化跟踪。
（2）流程管理工具：使用流程管理工具（如Jira、Trello等）实现对项目流程的版本控制。
这些工具可以帮助项目团队跟踪任务进度，提高协作效率。
三、版本控制方法的应用场景1. 项目文档管理在项目文档管理中，文件版本控制是确保文档一致性、准确性和可追溯性的关键。
gitlab工程化分支结构
gitlab工程化分支结构在开发软件项目的过程中，一个好的分支管理结构是非常重要的。
GitLab是一个强大的版本控制系统，在实施工程化分支结构时可以提供极大的帮助。
下面将介绍如何在GitLab中建立工程化的分支结构。
首先，建议使用GitLab Flow分支模型来组织分支结构。
GitLab Flow是一种基于Git分布式版本控制系统的工作流程模型，它能够提供清晰的分支结构和规范的合并策略。
根据GitLab Flow，我们需要为不同类型的任务创建不同的分支。
通常，我们会有以下几种类型的分支：1. 主分支（main branch）：主分支是主要用于生产环境的分支，也被称为“生产分支”或“稳定分支”。
该分支应该是最稳定和可靠的版本，并且应该只包含已经经过测试和验证的代码。
2. 开发分支（develop branch）：开发分支是用于日常开发的分支。
所有的新特性开发和bug修复都应该在该分支上进行。
通常，该分支会包含来自不同开发者的多个特性分支。
3. 特性分支（feature branch）：特性分支是用于开发单独的功能或特性的分支。
每个开发者在开发新功能时应该创建一个自己的特性分支，并在完成开发后将其合并到开发分支上。
4. 修复分支（fix branch）：修复分支是用于解决bug的分支。
当发现bug时，应该创建一个修复分支用于修复bug，并在修复完成后将其合并到开发分支和主分支上。
此外，为了更好地组织和管理代码，还可以考虑以下几种分支用途：5. 预发分支（staging branch）：预发分支用于进行预发布测试。
当开发分支中的功能开发完成后，将代码合并到预发分支，并进行功能和性能测试。
6. 版本分支（release branch）：版本分支用于准备发布新的版本。
当准备发布新的版本时，从开发分支上创建一个版本分支，在该分支上进行最后的测试和准备工作。
最后，在GitLab中建立这样的工程化分支结构需要一些命名规范和合并策略。
GitLab-普通用户使用指南
GitLab 普通用户使用指南1.简介GitLab作为一种仓库管理系统的开源项目，使用Git可以很好地管理项目的代码，从而帮助管理项目。
Git给用户提供了创建并使用项目、创建并邀请用户加入项目组等功能。
在高级软件工程课程中，Git主要是作为辅助工具来使用。
2.修改密码在开始使用之前，管理员已经为每个用户注册好了账号，用户登录之后，要先修改密码（登录后直接进入修改密码界面，见图1），密码为八位字符串。
图1 修改密码修改密码之后，重新登录系统，可以对Git进行下一步的操作。
3.创建项目组项目在多数的情况下要由项目组员配合完成，因此，用户在使用Git的时候，第一步需要做的就是要创建组。
创建项目组之后，将其他项目成员邀请进入该组。
创建和邀请的功能由一个组员完成就可，不需要多人重复操作。
修改密码之后，会自动退出至登录界面，重新登录之后，进入Git的欢迎界面，见图2.图2 欢迎界面若是管理员赋予了该登录用户新建工程和组的权限，那么，在欢迎界面中，就可以看到普通用户最基本的功能是新建工程、新建组、以及参加公有工程。
在新建项目组功能中，点击“New group”，可以进入新建项目组的界面，见图3.图3 新建组在图3所示的界面中，依次输入项目组名、详细信息、说明文件（可选），点击“Create Group”就可以完成新建项目组的功能。
新建项目组之后，会进入图4所示的界面，界面显示当前只有一个组“GroupForUserGuide”。
并且在此也可以点击“New project”，新建工程。
创建好项目组后，就要在项目组中添加组员，点击图4中的“Members”选项，进入图5所示的邀请组员界面。
图4 新建组后跳转到首页点击图5中的“Add members”，就可进入图6所示的界面。
在图6中，可以添加组员，并且为组员设置权限。
在高级软件工程课程中，组长邀请组员的时候，只需要将组员权限设置成Developer就可。
将多个组员邀请进入项目组之后，就可以新建工程了。
gitlab工程化分支结构
gitlab工程化分支结构在GitLab中，一个好的工程化分支结构能够提高团队的协作效率、代码的可维护性和品质。
以下是一些参考内容来帮助你建立一个有效的工程化分支结构。
1. Master分支（主分支）:- Master分支是项目的主要分支，应该始终处于可发布状态。
- 只有验证了的代码和测试通过的代码才能合并到Master分支中。
- Master分支应该用于发布的正式版本，每次合并到Master分支都应该与一个版本标签相关联。
2. Develop分支（开发分支）:- Develop分支是用于日常开发的分支，从Master分支派生出来。
- 所有的新功能开发和bug修复都应该在Develop分支上进行。
- 可以在Develop分支上进行集成测试来确保代码的功能正确性。
3. Feature分支（功能分支）:- 每个新特性或新功能都应该在一个独立的Feature分支上进行开发。
- Feature分支应该从Develop分支派生，并在开发完成后合并回Develop分支。
- 为了方便团队协作，可以使用命名约定来标识Feature分支，例如"feature/<feature_name>"。
4. Release分支（发布分支）:- Release分支用于发布新的正式版本。
- 在Develop分支上完成所有的功能开发和测试后，从Develop分支派生出一个Release分支。
- Release分支上可以进行最后的测试和修复bug。
- 当Release分支准备好发布时，将其合并回Master分支，并且与版本标签相关联。
5. Hotfix分支（修复分支）:- Hotfix分支用于修复Master分支上的紧急bug。
- Hotfix分支应该从Master分支派生，并且在修复完成后合并回Master分支。
- 为了方便团队协作，可以使用命名约定来标识Hotfix分支，例如"hotfix/<bug_number>"。
GIT使用入门详细教程
GIT使用入门Part 1第一章基本原理git是一个版本控制系统。
官方的解释是：版本控制(Revision control)是一种软件工程技巧，籍以在开发的过程中，确保由不同人所编辑的同一档案都得到更新。
按我的白话文解释就是：一群志同道合的人身处祖国各地，希望来合作开发一个项目，假设这个项目是使用c语言写的（当然用任何语言都可以的）。
那么大家怎么合作呢？用信件？效率太低。
用邮件，不好实现多人沟通。
用googlegroup吧，可开发阶段中的源代码没法科学管理。
用自建的网站吧，需要人力物力财力来支撑阿。
这个时候版本控制系统就派上用场了。
它可以让一个团队里的不同的人在不同地点、不同时间开发和改进同一个项目，并且在大部分的时间里，版本控制系统会聪明的帮你把不同的人在不同地点不同时间修改的代码融合到项目中去。
（当然在一些特殊的情况，还是需要人去决定到底哪些代码需要加入到项目中，这个在后面讨论不迟，先让大家对版本控制有一个好印象，呵呵）知道了版本控制系统的优点之后，下面就要具体实践和体验了。
建议你选用的版本控制系统包括：rcs，cvs，svn，git，Mercurial，Bazzar等等。
当然git，Mercurial和Bazzar都是属于分布式版本控制系统。
下面是一些网友对于这些版本控制系统评论的只言片语：1)svk配合svn可以实现分布式的版本控制。
2) 我是从SVN转到Git下的。
我想Git的优势是速度飞快，谁用谁知道！3) git的确是最快的，bzr慢的要死4) SVN 在windows 下有TortoiseSVN5) git 有Windows 版本，在google code 上的项目。
/p/msysgit/6) 大家可以试试国内提供的git服务。
那么，简单地说，Git 究竟是怎样的一个系统呢？请注意，接下来的内容非常重要，若是理解了Git 的思想和基本的工作原理，用起来就会知其所以然，游刃有余。
在开始学习Git 的时候，请不要尝试把各种概念和其他的版本控制系统诸如Subversion 和Perforce 等相比拟，否则容易混淆每个操作的实际意义。
软件工程的代码管理
软件工程的代码管理代码是软件工程中不可或缺的一部分，对于软件项目的成功开发和维护来说，代码管理起着至关重要的作用。
良好的代码管理能够提高开发效率，降低开发成本，保证代码质量，便于团队协作和项目追踪。
本文将介绍软件工程中常用的代码管理方法及其优势。
一、版本控制系统版本控制系统是代码管理的基础工具，通过记录和管理代码的变更历史，实现团队协作和代码追踪。
目前主流的版本控制系统有集中式和分布式两种类型。
1. 集中式版本控制系统集中式版本控制系统使用中央服务器存储代码库，每个开发者从服务器上获取代码并提交修改。
常见的集中式版本控制系统有CVS和SVN。
它们的优势在于简单易用，适合中小型团队或个人项目。
然而，由于依赖中央服务器，当服务器故障或网络不通时，开发者将无法正常工作。
2. 分布式版本控制系统分布式版本控制系统将完整的代码库复制到每个开发者的本地，开发者可以在本地进行修改，并与其他开发者的代码合并。
常见的分布式版本控制系统有Git和Mercurial。
分布式版本控制系统优势在于灵活性和性能，开发者可以离线工作，无需依赖中央服务器。
此外，分布式版本控制系统具备强大的分支管理能力，能够高效地处理复杂的开发流程。
二、代码库管理代码库是存储软件项目代码的地方，管理代码库对于团队协作和项目追踪至关重要。
1. 单一代码库单一代码库指的是将整个软件项目的代码存储在一个代码库中。
这种管理方式适合小型项目或初创团队，简单直观。
然而，当项目规模庞大或团队成员众多时，单一代码库可能导致代码库过于庞大和冲突增多，影响开发效率。
2. 多模块代码库多模块代码库将软件项目按模块划分，每个模块独立存储在一个代码库中。
这种管理方式适合大型项目或分布式团队，能够降低代码库的冲突风险，提高开发效率和团队协作能力。
同时，多模块代码库还能够借助子模块和依赖管理工具，实现模块间的复用和解耦。
三、代码分支管理代码分支是指在代码库中创建的一份独立的代码副本。
TortoiseGit使用入门
TortoiseGit使用入门首先要确定TortoiseGit已找到msysgit,如果先安装msysgit 再装TortoiseGit, 一般TortoiseGit 就会自动的识别。
安装详见TortoiseGit安装教程（安装的时候，除了修改安装路径外，其他都必须默认！！尤其第一步一定要选择putty的ssh）设置与查询的方法,这里从开始菜单进入设置。
这是TortoiseGit的设置界面，可以看到用来定位MSysGit的路径。
点“Check now”检查有效性。
如果有错的话,就自己设置msysgit的bin文件路径。
右击任意文件夹，可以看到TortoiseGit已经嵌入右键了。
“Git Clone...”是获得远程的版本库,“Git Create repository here”是将选定的文件夹作为要创建的版本库。
在要创建版本库的文件夹中点“Git Create repository here”后,会显示：点“Ok”就会在该文件夹的根目录自动创建一个隐藏文件夹".git" 。
注意：最好找个空的文件夹练习操作，或者备份文件夹。
比如误选了Clean up把无版本控制的文件都删了,哭都来不及-_-。
现在，用git初始化过的文件夹就不一样啦!!不仅文件都有附加的绿钩图标(此为已添加进版本库且未被修改过的文件),右键菜单也多了操作选项。
将要使用git版本库管理的文件,选择后用git的菜单add进去master是Git默认的主要分支（主干）,适合单人独自开发。
多人开发时可以给每个人创建一个分支。
按Git Commit -> “master”是将所选文件夹内容提交到用于汇总的库上。
（不知道的话，千万不要随便按）提交修改后,出现：以上就是如何提交更改到本地的版本库,所以无论有无网络Git都可以用。
远程使用Git本地Commit(提交)后,下面介绍的就是Push到远程啦.这里以Git与通信为例。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
• 前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的： • 第一步是用git add把文件添加迚去，实际上就是把文件修改添加到暂
存区stage；
• 第二步是用git commit提交更改，实际上就是把暂存区的所有内容提
交到当前分支。
撤销修改
• 命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部
他人.
• Git跟踪的是内容而不是文件,它对于重命名文件的合并有更好的支持. • Git代码库的大小相对于SVN来说小很多. • 目前Git不支持代码库的部分checkout/clone,但是正在开发中,而且已经有
submodule方面的支持.SVN则可以根据需要只从代码库中checkout某个子文件 夹.SVN的版本号更短并且可以预知,而Git的版本号则是40位的16迚制数字串.
分支管理
• • • • •
Git鼓励大量使用分支： 查看分支：git branch 创建分支：git branch <name> 切换分支：git checkout <name>
创建+切换分支：git checkout -b <name>
合并某分支到当前分支：git merge <name> 删除分支：git branch -d <name>
集中式vs分布式
在分布式管理系统中,你可以在自己本地磁盘上拥有代码库的完整拷贝,对代 码库的操作不需要通过网络向中央服务器迚行请求,因此速度会非常的快.特 别是你在迚行查看日志,与旧版本代码迚行比较或者其它需要完整代码库的操 作时,这种速度上的改善会非常明显.对于集中式的系统,在局域网内你也许只 会觉得有点慢,但如果当你工作在一个分布式的项目中,你的代码库在另一个 大洲的时候,这就会是非常大的问题了. 如果你经常在四处奔走,无法随时与代码库建立网络连接,那么一个分布式的 管理系统会使你可以随时与代码库一起工作.你可以随时随地提交你的工作, 浏览历史,并且比较版本间的差异.
撤销，这里有两种情冴：
• 一种是readຫໍສະໝຸດ e.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版
本库一模一样的状态；
• 一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到
添加到暂存区后的状态。
• 总之，就是让这个文件回到最近一次git commit或git add时的状态。
• 每一份代码拷贝都可以作为代码库及其更改历史的一份进程备份,这就为数据
• • • • •
Git有一个"clean"命令.SVN急需这个命令.
Git有一个"bisect"命令. SVN会在每一个文件夹中创建一个.svn目录.而Git只会创建一个.git目录.
在SVN中,每一个文件或文件夹都可能来自于一个不同的版本或是branch.这很 可能会引起混乱.
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交， 合并完成。 用git log --graph命令可以看到分支合并图。 分支策略:
在实际开发中，我们应该按照几个基本原则迚行分支管理： 首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不 能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某 个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发 布1.0版本； 你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不 时地往dev分支上合并就可以了。 所以，团队合作的分支看起来就像这样：
讨论？
谢谢！
• 另一种方式是用git stash pop，恢复的同时把stash内容也删了： • 你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，
用命令：git stash apply stash@{0}
多人协作
• 查看进程库信息，使用git remote -v； • 本地新建的分支如果不推送到进程，对其他人就是不可见的； • 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull
标签管理
• 创建标签： • 命令git tag <name>用于新建一个标签，默认为HEAD，也可以指定一
个commit id；
• git tag -a <tagname> -m "blablabla..."可以指定标签信息； • git tag -s <tagname> -m "blablabla..."可以用PGP签名标签；
git checkout -- file命令中的--很重要，没有--，就变成了“创建一个新分支”的命 令，我们在后面的分支管理中会再次遇到git checkout命令。 Git同样告诉我们，用命令git reset HEAD file可以把暂存区的修改撤销掉 （unstage），重新放回工作区 场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命 令git checkout -- file。 场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃 修改，分两步，第一步用命令git reset HEAD file，就回到了场景1，第二步按场 景1操作。 场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回 退一节，不过前提是没有推送到进程库。
而且必须联网才能使用。有一些商用的版本控制系统，虽然比CVS、 SVN好用，但那是付费的，和Linux的开源精神不符。
• 集中式版本控制系统： CVS、SVN 、IBM的ClearCase、微软的VSS • 分布式版本控制系统：除了Git以及促使Git诞生的BitKeeper外，还有
类似Git的Mercurial和Bazaar等
GIT的工程管理和简 单使用
孙振银20150316
目录
• GIT简介 • GIT安装配置 • GIT基本使用
GIT简介
• Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是
Git！一个月之内，Linux系统的源码已经由Git管理了！
• Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，
GIT安装配置
• 如何访问gerrit和下载git代码
GIT基本使用
• 初始化一个Git仓库，使用git init命令。 • 添加文件到Git仓库，分两步： • 第一步，使用命令git add <file>，注意，可反复多次使用，添加多个
文件；
• 第二步，使用命令git commit，完成。 • 要随时掌握工作区的状态，使用git status命令。 • 如果git status告诉你有文件被修改过，用git diff可以查看修改内容
版本回退
• git log命令显示从最近到最进的提交日志，如果嫌输出信息太多，看得眼花缭乱的，
可以试试加上 --pretty=oneline参数：
• Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的
提交的版本，上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100 个版本写100个^比较容易数不过来，所以写成HEAD~100
• 无论你什么时候删除了点东西,你都需要告诉SVN一声.Git会自己发现并处理. • 在Git中,忽略语法很简单,例如*.pyc,它会被应用到所有的子文件夹.当然,如果你
只想忽略某个特定文件夹中的内容,也是可以的.在SVN中,很难有什么方法可以 将一个忽略模式应用到所有的子文件夹中.
• Git中忽略设置是"private"的,这些设置包含在.git/info/exclude中,并不会影响到其
• 分布式系统(git)与集中式系统(svn)的几个重要的区别: • 本地开发不需要与中央服务器迚行通信,因此一般的操作(如提交,查看历史和
还原修改等)的执行速度非常快.只有在向其它端点push代码更改或者从其它端 点pull代码更改的时候才会需要迚行通信. 丢失提供了天然的保护. 极其强大的分支管理
• HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用
命令git reset --hard commit_id。
• 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。 • 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。
工作区和暂存区
命令git tag可以查看所有标签： 命令git push origin <tagname>可以推送一个本地标签； 命令git push origin --tags可以推送全部未推送过的本地标签； 命令git tag -d <tagname>可以删除一个本地标签； 命令git push origin :refs/tags/<tagname>可以删除一个进程标签。
Bug分支管理
• 修复bug时，我们会通过创建新的bug分支迚行修复，然后合并，最后删除； • 当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复
后，再git stash pop，回到工作现场。