Git和团队开发（针对虚拟对象）

文章的共同作者： RicardoMilos

引言

你好 如果您来到这里，那么您将对程序员如何在团队中工作的问题感兴趣。 如果在那之前您仅是单打独斗，那么在您看来，在团队中工作会更容易，因为手更多，这意味着您可以更快地完成工作。 但不是那么简单。 现在，我们将熟悉正在开发的工具以及团队内部正在发生的事情。

吉特

当然，您熟悉这种情况：



这是一个版本控制问题。 通常，在不断重做一切并实现理想的富有创造力的人中会出现这种问题。 不幸的是，在编程中，第一次也并非总是正确。 想象一下一种情况：您想出了如何重做一些代码，以便使其工作更快一些。 您重写，编译，运行并了解该程序现在根本无法运行。 一切都坏了。

在这里，您意识到尚未保存工作选项，并且键盘上的Z按钮已损坏，因此您甚至无法发送ctrl + z垃圾邮件。 愤怒的是，您用抽着的右手突破了监护仪。 晚上，您哭泣，裹着毯子，想一想程序员的困境。

令人遗憾的情况...为了防止这种情况的发生，您需要保存代码的版本。

好吧，程序员是个聪明人，他们完全理解以文件堆的形式存储所有版本并不是很方便，并且迫切需要发明一些东西来促进版本的存储并解决版本问题。

在这里，我们可以比喻游戏。 几乎所有AAA项目都有保存系统。 很好的例子是游戏Papers Please。



几乎所有版本控制系统都可以正常工作。

版本控制系统（VCS）是一个长时间记录对一个文件或一组文件的更改的系统，以便以后可以返回到特定版本。

SLE分类：

1. 本地的
2. 集中式
3. 分散式

我们已经弄清楚了本地硬通货（这些是相同文件的相同堆）

集中硬通货

• 中央服务器
  所有文件均受版本控制
• 许多客户
  接收文件副本

范例：

• CVS
• 颠覆
• Perforce

分布式硬通货

1. 客户完全复制整个存储库
2. 中央服务器负责提供主副本
3. 同步可能是
   
   • 与服务器
   • 与任何客户
   
   

范例：

• 吉特
• 水星
• 集市

为什么需要SLE

1. 存储所有项目更改
2. 切换到“项目的任何阶段”的能力
3. 进行团队同步开发的能力
4. 解决以下问题的能力

吉特

Git-分布式版本控制系统
张贴者：Linus Torvalds
2005年-第一版

安装方式：
Linux：sudo apt安装git
Windows / macOS： 链接

开发人员使用：

• GNU / Linux
• 安卓系统
• 酒类
• 谷歌
• 铬色
• jQuery的
• p
• MediaWiki
• t

基本概念

仓库 （repository，repo）-硬通货存储元数据和项目对象数据库的地方
工作目录 -从存储库中提取的项目特定版本的副本
准备区域 （暂存区域）-一个服务文件，其中包含有关项目下一个修订版本应包括的内容的信息
修订版 （revision）-一个存储项目状态更改的对象（项目版本）
提交 -创建新修订

配置GIT

用户名设定

git config --global user.name "Your Name" git config --global user.email you@abc.net 

设置保存在隐藏的.gitconfig文件中（在用户的主目录中）

 [user] name = John Doe email = jdoe@example.com 

创建存储库

 mkdir first_git_repo cd first_git_repo git init 

项目文件状态

1. 固定的
   该文件已经在存储库中
2. 已修改
   该文件的内容与其提交状态不同
3. 准备好的
   创建新修订版本后将提交的已修改文件（此文件将属于此修订版本）

使用代码

• 储存库初始化
  
  

   git init 

• 或切换到特定版本
  

   git checkout _ 

1. 更改项目代码：创建/删除/编辑文件
   在任何IDE中
2. 查看状态
   git status
3. 将修改的文件添加到索引
   （过渡到暂存状态）
   git add ___
4. 创建修订（从暂存到回购）
   git commit -m ""

总结一下

使用硬通货

存储什么？

[+]所有源代码文件
[+]编译所需的所有资源
[+]项目编译设置
IDE中的[-]项目设置
[-]从源代码编译的文件
[-]可执行文件

从索引中删除

git rm _

提交可能包含对多个文件的更改

什么时候提交？

• 当我完成一个小任务时
• 如果问题很大-分为逻辑子部分
• 该代码必须可操作！

查看历史

 git log git log --graph 

修订号= SHA-1更改哈希

切换至审核

 git checkout sha1_hash git checkout _8__sha1 

分行

分支是一系列提交，其中并行开发功能

主分支- 主

GIT中的分支

显示存储库中现有的所有分支

git branch

创建分支

git branch

切换到分支

git checkout
目前不应有未保存的更改。

创建一个分支并切换到它

git checkout -b

合并分支

合并分支-将更改（提交）从一个分支集成到另一个分支的过程：

b1-我们向其添加更改的分支
b2-从中添加更改的分支

 git checkout b1 git merge b2 

查看历史

窗口实用程序：

• gitg
• gitk
• gitx
• gitKraken

删除分支

删除分支

git branch –d _

删除分支

git branch –D _

或者说，删除分支而不等待提交移至主节点

未保存的更改缓冲区

还是“如果需要切换到另一个分支并提早提交该怎么办？”

将更改写入临时缓冲区

git stash

从缓冲区中提取这些更改

git stash pop

有用的链接：

git-scm.com/book/en/v2
githowto.com/ru
en.wikipedia.org/wiki/version_system

团队发展

因此，如果您达到这一行，则意味着您至少对git有一点了解（我真的希望如此）。 但是团队发展呢？ 让我们更详细地研究这个问题。

一个幽默的小难题：

鉴于：

• N个开发商
• 工作地点
• 职权范围（TOR）
• 互联网

问题：

• 如何在不引起有秩序的注意的情况下进行项目？

答案是：

• 团队协作良好，工作努力

嗯，什么是团队？ 她是什么样的人？

团队是少数人：

• 具有互补的技能（有人在编程，有人在设计等）
• 追求共同的目标（为了获得完全的自我满足，他们都需要履行客户的任务）
• 共同承担实现项目目标的责任（如果某个团队成员突然间遇到自己的传统知识方面的困难，他的队友将总是向他提供帮助（这不应被滥用，否则对于团队而言，您根本就没有必要））。

一个非常重要的注意事项：在团队中，您应该感到绝对自在并尝试与整个团队相处，否则一切都可能出错。

因此，现在您了解了什么是团队。 但是下一个问题出现在您的脑海中（是的，是的，本文的作者可以理解）：“谁负责团队中的工作？ 每个人都有自己的位置吗？ 还是每个人都在做自己想要的？”

自然，团队中的每个参与者都有自己的角色和任务。 确实，没有开发产品，而是会有混乱。 让我们看一下命令编程中的角色：

1. 团队负责人：
   
   团队负责人是项目经理和合格的开发人员之间的桥梁。
   
   在项目中有两个主要角色：管理人员-PM和技术人员-系统架构师。 蒂姆利德（Timlid）部分地履行了这两个角色，但他的职责重点是管理（强调技术部分是技术负责人）。
   
   “团队负责人1：关怀您的团队。 团队应在工作环境中感到自在，并有良好的动力。 此外，团队负责人还为他的孩子提供专业和职业发展，定期就人们感兴趣的发展话题进行讨论，并在此方面给予帮助。”
   
   团队负责人的管理角色包括以下职责：管理，任务分配和委派，各种评估和进度安排，监视项目状态以及会议，与客户，管理层和所有团队成员（开发人员，测试人员，管理人员）进行沟通。
   
   在技​​术角色下：参与技术文档的撰写，项目技术的选择，架构开发，研发，代码审查，初级人员的指导，进行技术面试，新团队成员在工作过程中的积极参与，对项目技术部分的责任。
   
   Timlid的典型工作日包括：
   
   
   • 考虑新任务及其分配
   • 与团队站起来
   • 集会
   • 程式设计
   • 建筑问题
   • 代码审查
2. 项目经理：
   
   项目经理是一位专家，其主要任务是管理整个项目：设计和确定优先级，安排任务，监视，沟通和快速解决问题。
   
   PM的主要职责是利用现有资源按时实现客户的想法。 作为此任务的一部分，PM需要制定开发计划，组织团队，建立项目工作流程，在团队与客户之间提供反馈，消除对团队的干扰以及按时控制产品的质量和交付。
   
   PM任务可以分为战术任务和战略任务。 战术上的-这是解决项目日常问题，消除团队障碍的解决方案。 战略性的目标是协调项目的总体目标，实现目标的路径以及行动的速度。
   
   “ PM的主要目标声明是：“我们需要这样做”，这意味着团队将在合理的时间内以合理的质量水平提供结果。”
3. 测试人员：
   
   测试人员是从事软件产品测试以识别其工作中的错误及其后续纠正的专家。
   
   测试人员的主要职责：
   
   
   • 开发产品的质量控制。
   • 识别和分析用户使用软件产品时遇到的错误和问题。
   • 自动测试的开发及其常规运行。
   • 测试脚本开发。
   • 记录发现的缺陷。
4. 开发人员：
   
   
   • 初级：
     Junior是入门级开发人员。
     
     完成实习后，一个人变成了一个成熟的六月。 对它的主要要求是能够独立执行技术任务。 如果项目是建立在体系结构中的，则它应立即实现另一部分典型的应用程序逻辑。 尽管Junior可能会时不时地犯错误，但不了解细微差别，与团队负责人讨论实施计划或与他一起检查完成的代码。
     
     您需要了解，对于签署者将在十分钟内解决的任务，六月可能需要每小时使用三种方法，并且在此过程中，必须完全重写代码，从而花费大量额外精力。 重要的是不要害怕这种感觉并保持平衡：什么时候推动，自己解决问题，相反，什么时候停止将额头撞在墙上，浪费项目时间，并寻求帮助。 用“我仍然是六月”一词来说明您的表现欠佳，这是个坏主意。
   • 中：
     
     中级-中级开发人员。
     
     对中级开发人员的主要要求是能够独立执行分配给他的任务的能力。 与上段内容非常相似，对吗？ 但是，有一个重要的警告-这里缺少“技术”一词。 也就是说，在新的水平上，您需要了解业务需求并将其转换为技术解决方案。
     
     通过这种方式：
     
     
     1. 中级开发人员了解应用程序在做什么。 这使您可以更好地理解任务，因此可以更准确地评估任务并更好地实施。 如果要求不能完全满足某个场景，那么好的开发人员将在计划阶段对此加以注意。 当应用程序因任何非标准用户操作而开始崩溃时，情况并非如此。
     2. 中级开发人员在自己的领域中构建应用程序时熟悉标准模板和解决方案，了解为什么需要它们，并且知道如何应用它们。 决策的标准化在代码的集体开发中非常重要，因为它使新手可以快速找出问题所在，并最大程度地减少错误。 了解典型应用程序的结构使从头开始构建它的任务变得微不足道，可以让您谈论正确实现的原理，并区分好代码与坏代码。
     3. 中级开发人员知道没有人能奏效。 他知道如何与其他团队成员进行交互：他可以与设计师讨论困难的时刻，与业务分析师一起阐明不完整的需求或与项目架构师（如果有的话）协调一些重要的技术解决方案，当然还拥有适当的集体开发工具。
   • 高级：
     
     Senior是一个高级开发人员，他看过很多代码，掌握了很多知识，并从中得出了正确的结论。 Signor的主要任务是在项目中做出正确的技术决策。 “正确的”是那些可以最大程度地提高业务收益和最小化成本的方法。 一个好的签约者不仅了解团队正在开发什么，而且还考虑完成的应用程序应解决哪些任务。 在开发拍卖站点时，签名者总是想知道峰值负载，并试图预见要竞争性地写入数据库表的尝试。 他事先考虑了系统的瓶颈，扩展系统的可能性，并牢记了由于工具使用不当而引起的漏洞和问题。
     
     这样的专家做得很棒，它甚至可以在问题出现之前解决问题。 从外部看，它就像有远见的天赋。 但是，如果您的项目生死攸关，并且您经常不得不扔掉并重写代码段-这些是项目未得到签名者足够重视的症状。
5. 设计师：
   
   设计师是一个设计人。 从逻辑上讲，不是吗？
   
   设计师的工作早在第一个像素出现之前就开始了，而比最后一个像素晚了很多。
   
   大多数人习惯于认为设计实际上是一组图片，颜色和字体，这些图片，颜色和字体会传递给布局设计师和程序员来制作产品。 有时候这种方法行得通，但更多的是它变成了一个项目，然后很难将其添加到产品组合中。
   
   事实是解决问题还不够。 在这个过程中，优秀的设计师将经历四个步骤。 它们是：
   
   • 了解问题：
     
     这项工作始于对问题的理解，就像带衣架的剧院：直到您放弃外衣，您才能继续前进。 如果您不深入研究问题，将获得不可行的产品。
   • 搜索解决方案：
     
     当问题明确后，就该寻找解决方案了。 用既定术语来说，这些都是各种草图和原型，有助于建立最终产品的初步构想。
   • 设计图
     
     这只是绘制图片和选择字体。 许多设计师从这里开始并立即完成工作，并且可以在Dribble或Behans大量看到这样的设计师的工作结果。
   • 批准：
     
     即使您的头和纸上有了苗条优雅的解决方案，这并不意味着对于客户而言，它看起来将是相同的。 如果您省略了此阶段，只是为客户提供了最佳实践，那么充其量您将根据自己的理解进行重做。 客户端编辑后最终将保留的内容与您的工作有点像。
   
   

好了，现在，您终于熟悉了团队开发中的所有职位。 在这里，我只列出了与编程相关的帖子。 如果我们将软件产品的开发视为业务项目，那么当然将会增加更多的角色，例如会计师，营销人员等。

结论

好吧，如果您读到这一点-恭喜，您真是太酷了！ 不，是的，真的，您的大脑还没有掌握如此多的信息吗？ 我希望不会。

因此，我希望我们的文章能帮助您了解团队开发的所有复杂性。 而且您对此主题没有任何疑问。 而且，当您来到一家超级傻瓜级，虚幻而又著名的公司时，就会被录用（如果他们只是拒绝接受），那么您就不会感到困惑，并向老板展示主要程序员是谁。 或者，也许您将创建自己的公司，谁知道;-)

感谢您的关注！

聚苯乙烯

这篇文章是由MSHP（莫斯科编程学院）的学生根据工业编程课程的演讲编写的。