linux操作git步骤

1、在linux新建文件夹

mkdir semantic_understand
cd semantic_understand

2、初始化，并克隆远端git项目

git config --global user.name "name"
git config --global user.email "zhangxianrong@tydic.com"
git clone http://gitlab.dicfin.com/zhangxianrong/nlu.git

3、进入，上传某个文件。

cd nlu
touch README.md

1023 2021-05-26 14:52:20 git add README.md
1024 2021-05-26 14:52:28 git commit -m "add README"
1025 2021-05-26 14:52:41 git push -u origin master

4、上传某个文件夹

 1027  2021-05-26 14:53:35  mkdir raw_data
 1028  2021-05-26 14:53:37  ls
 1029  2021-05-26 14:53:40  cd raw_data/
 1030  2021-05-26 14:53:41  ls
 1031  2021-05-26 14:54:57  cd ../
 1032  2021-05-26 14:54:59  ls
 1033  2021-05-26 15:04:34  cd raw_data/
 1034  2021-05-26 15:04:35  ls
 1035  2021-05-26 15:04:37  git add . 
 1036  2021-05-26 15:05:03  git commit  -m  "初始数据" 
 1037  2021-05-26 15:05:18  git push -u origin master

 5、删除某个文件

 1012  2021-06-10 18:00:45  git rm all.txt
 1014  2021-06-10 18:01:44  git commit -m "delete"
 1015  2021-06-10 18:02:14  git push -u origin master

 1、优缺点

优点：

1.分布式开发时，可以git clone克隆一个本地版本，然后在本地进行操作提交，本地可以完成一个完整的版本控制。在发布的时 候，使用git push来推送到远程即可。

2.git分支的本质是一个指向提交快照的指针，速度快、灵活，分支之间可以任意切换。都可以在本地进行操作可以不同步到远程

3.冲突解决，多人开发很容易就会出现冲突，可以先pull远程到本地，然后在本地合并一下分支，解决好冲突，在push到远程即 可。

4.离线工作，如果git服务器出现问题，也可以在本地进行切换分支的操作，等联网后再提交、合并等操作。

缺点：

1.git没有严格的权限控制，一般是通过系统设置文件的读写权限来做权限控制。

2.工作目录只能是整个目录，而svn可以单独checkout某个有权限的目录。

3.git上手可能没有svn那边顺手，需要经过学习一下。

总结：

1.如果对访问控制、权限分配和代码安全性等要求比较高的，建议使用svn。

2.如果是分布式，多人开发，版本迭代比较快的项目，建议使用git。

 2、相关分析

gitlab就是一种版本管理，代码review，任务管理，项目管理，持续集成五合一的平台。它主要用yml文件来配置，优化点就是缓存了，缓存是通过键值来提取的，你可以使用系统变量来配置是某一个分支缓存还是某一个提交缓存，避免了每次都要进行重复性劳动，也避免了缓存过期。第二个优化点就是label，label这个东西非常好用，团队之间沟通要微信沟通还是当面沟通都是非常累的一件事，如果你对你的MR和任务用一个简洁易懂的label描述一下，大家就能很好的知道这是一件什么事，它进行到哪一步了。第三个优化点是配置提交格式，gitlab对commit message是可以配置格式的，在settings里面，这是因为统一的格式可以减少复杂度，增强可理解性，从而减少理解时间的浪费。第四个优化点就是在一个job里面做尽可能多的事情，用久了gitlab我们就知道每一个job都需要有准备时间，可能还要保存缓存和提取缓存，如果job少了，在这上面浪费的时间就少了。

目标：200%更快的DevOps生命周期

从项目计划和源代码管理到CI/CD和监控，GitLab是整个DevOps生命周期的单一应用。只有GitLab允许并行的DevOpes，使得软件生命周期200%更快。

這里的CI/CD其实指的是持续集成（CI）和持续交付（CD），CI就是软件工程师每天频繁地将更新代码的副本传递到共享位置的过程。所有的开发工作都在预定的时间或事件中进行集成，然后自动测试和构建工作。通过CI，开发过程中出现的错误能被及时发现，这样不仅加速了整个开发周期，而且使软件工程师的工作效率更高。而CD 表示持续交付（CD）是创建高质量应用程序的第二个难题。CD是一门软件开发学科，利用技术和工具快速地交付生产阶段的代码。由于大部分交付周期都是自动化的，所以这些交付能够快速地完成。这方面的知识可以参参考https://blog.csdn.net/rancherlabs/article/details/80133523 ，這也是一门大学课

GitLab 工作流介绍

其实gitlab的核心还是提供了一种简单、透明和有效的 git 工作方式，并与问题跟踪系统相结合。這就是GitLab 工作流介绍（GitLab Flow）

使用版本控制中常见的问题是，随着时间推移，产生越来越多的分支，在那些长期维护的分支中充斥着杂乱的修改内容。

• git 工作流的问题

git 工作流主要的问题是：一、默认的 master 分支只是用于发布，开发都在其他分支上。二、对于多数应用来说过于复杂，特别是 release 和 hotfix 分支的不可部署导致使用上的复杂。

GitLab 工作流的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。

对于"持续发布"的项目，它建议在master分支以外，再建立不同的环境分支。比如，"开发环境"的分支是master，"预发环境"的分支是pre-production，"生产环境"的分支是production。

开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。

只有紧急情况，才允许跳过上游，直接合并到下游分支。

协作

在一个 GitLab 项目上一起工作的最简单方法就是赋予协作者对 git 版本库的直接 push 权限。 你可以通过项目设定的 “Members（成员）” 部分向一个项目添加写作者，并且将这个新的协作者与一个访问级别关联（不同的访问级别在 组 中已简单讨论）。 通过赋予一个协作者 “Developer（开发者）” 或者更高的访问级别，这个用户就可以毫无约束地直接向版本库或者向分支进行提交。

另外一个让合作更解耦的方法就是使用合并请求。 它的优点在于让任何能够看到这个项目的协作者在被管控的情况下对这个项目作出贡献。 可以直接访问的协作者能够简单的创建一个分支，向这个分支进行提交，也可以开启一个向 master 或者其他任何一个分支的合并请求。 对版本库没有推送权限的协作者则可以 “fork” 这个版本库（即创建属于自己的这个库的副本），向 那个 副本进行提交，然后从那个副本开启一个到主项目的合并请求。 这个模型使得项目拥有者完全控制着向版本库的提交，以及什么时候允许加入陌生协作者的贡献。（这有点类似 github，但目前github私有库收费）

在 GitLab 中合并请求和问题是一个长久讨论的主要部分。 每一个合并请求都允许在提出改变的行进行讨论（它支持一个轻量级的代码审查），也允许对一个总体性话题进行讨论。 两者都可以被分配给用户，或者组织到 milestones（里程碑） 界面。

这个部分主要聚焦于在 GitLab 中与 Git 相关的特性，但是 GitLab 作为一个成熟的系统，它提供了许多其他产品来帮助你协同工作，例如项目 wiki 与系统维护工具。 GitLab 的一个优点在于，服务器设置和运行以后，你将很少需要调整配置文件或通过 SSH 连接服务器；绝大多数的管理和日常使用都可以在浏览器界面中完成。

3、持续集成讲解

在最好的时候创建用户喜欢的高质量应用程序并不是件容易的事情。更何况，要怎样做才能更快地创建用户喜欢的高质量应用程序并且能够不断改进它们呢？这就是需要引入持续集成和持续交付（CI / CD）的地方。

持续集成（CI）

什么是持续集成？
那么，持续集成（CI）究竟是什么呢？它是软件工程师每天频繁地将更新代码的副本传递到共享位置的过程。所有的开发工作都在预定的时间或事件中进行集成，然后自动测试和构建工作。通过CI，开发过程中出现的错误能被及时发现，这样不仅加速了整个开发周期，而且使软件工程师的工作效率更高。

持续集成有什么好处？
我们不能低估CI的好处。因为团队里的人都在同一个产品上进行实时工作，所以在软件开发过程中使用CI时，你可以期望实现更快的速度、更好的稳定性和更强的可靠性。并且在开发过程的早期，开发人员能够发现和解决任何编码问题，使它们在成为下游主要问题之前得到纠正。这样可以降低错误代码导致的长期开发（和业务）的成本。

持续集成对于QA测试花费的时间也有很大的影响。通过CI，开发人员不断审查和编辑以前的代码，能够检查到许多小的错误，这些错误在QA里通常发现的晚一些。这使得测试人员不仅可以专注研究代码和关注更加紧迫的问题，而且能够同时测试更多的场景。

对开发团队来说，使用CI的另一个好处是可以提高编码能力。由于持续发展的自然灵活性，这使得开发人员能够快速、轻松地对代码进行更改，却不会产生运行回归风险。

持续交付（CD）

什么是持续交付？
持续交付（CD）是创建高质量应用程序的第二个难题。CD是一门软件开发学科，利用技术和工具快速地交付生产阶段的代码。由于大部分交付周期都是自动化的，所以这些交付能够快速地完成。

持续交付有什么好处？
实施持续交付的主要好处是能够加快应用程序的上市时间。使用CD的公司能大大增加他们的应用程序发行频率。在没有使用CD之前，应用程序发布的频率通常是几个月一次。然而现在使用CD，你可以一个星期发布一次、甚至每天发布多次应用。在竞争激烈的行业中，速度的提高将会使你处于主要优势。

持续不断的软件版本发布也会根据用户对应用程序的反馈，允许开发团队对其进行微调。这个用户反馈为开发人员提供了所需要的洞察力，并且它优先考虑了用户实际需要的功能请求。同样重要的是，对用户实际上没有用到的应用程序功能，它允许开发人员对其进行优先级排序。

CD的另一个好处是它能保证每个发行版本的风险较低。当使用CD方法发布时，开发团队也会更有信心，因为在整个开发生命周期中，所有内容都经过了多次测试。

任何不考虑转向CI / CD的公司都或将被那些使用CI / CD方法的竞争对手远远地甩在后面。那么，如何转向CI / CD？当您准备转向持续集成／持续交付（CI / CD）时，需要考量及决定的相关流程有很多。下文将带您了解这些主要流程。

转向CI/CD的重要流程
1、分支和合并
你需要组织及考虑的一个主要流程就是你的分支和合并。分支就是开发人员可以在代码的平行部分工作的地方——从一个中央代码库分支出来。分支的好处在于，它允许在不破坏中心代码基础的情况下，在软件构建的不同方面同时进行工作。显然，合并即意味着分支合并到核心代码库。

通过各种版本控制系统，许多开发人员对分支和合并已经很熟悉了。然而，根据您的构建的特别要求，您所分支的内容也有很多不同的策略。有些开发人员将通过维护、功能或团队来进行发布的分支。

您可能会对某种策略非常狂热，但“绝对正确”的分支和合并策略是不存在的，只存在“对您的构建而言正确”的方式与策略。这需要检查您当前的分支和合并策略，并根据您的目标和情况决定需要更改哪些内容。

2、构建自动化
构建自动化意味着您可以自动编译软件构建。持续集成服务器的核心是构建自动化服务器，其工作是在触发或定时的基础上编译和链接源代码。您选择的持续集成服务器将成为您的CI/CD环境的支柱。

在查看构建自动化过程时，了解市场上各种可用选项的功能是非常有帮助的。开源公司Jenkins现在在CI/CD部署中占绝对优势，这通常是一个好的开始。或者至少，在比较其他解决方案时把它作为基准。作为一个开源代码系统，您可能仍需构建一些实用程序,以使构建自动化完全适合您的情况。

3、测试自动化
测试自动化对于CI/CD能否按预期工作至关重要。如果没有自动化测试，CI/CD将很快无法实现快速交付的目标。我们的总体建议是尽可能自动化。这意味着您需要检查您需要执行的各种测试，并决定在您的环境中可以安全地自动进行哪些测试。

建立测试自动化环境可能需要新的技能。然而，这是战略需求，将会提高交付速度，减少错误。至少，您应该自动化代码审查、单元测试、集成测试和系统测试。

4、部署自动化
关于持续交付和持续部署之间的区别，仍然存在一些混淆。简而言之，持续交付意味着持续推出发布就绪代码，而持续部署则意味着持续给用户部署该软件。

无论你在看什么“CD”，对那些不习惯的人来说，这似乎是一个巨大的飞跃。为了让您的组织有信心将软件部署到最终用户，需要一个严密的测试自动化基础设施。

我们的建议是，最好进入流程定义，以实现零接触持续部署的总体目标。虽然领先的持续集成系统通常会考虑自己的持续交付系统，但您可以比现成的参数更进一步。真正的敏捷性需要构建一个基础设施、写好代码，吸引用户使用。

选择开源且完整的CI/CD的工具
真正实现CI／CD并非易事，pipeline搭建工作复杂，平滑升级难以保障，服务宕机难以避免……选择一个完整的CI/CD工具，将大大助力于CI/CD在企业里落地并最终带来生产运维效率的提升。Rancher Labs新近发布的CI/CD工具Rancher Pipeline，就拥有极简的操作体验，强大的功能整合，并且完全开源。

同时支持多源码管理：在单一环境中同时拉取、使用和管理托管在GitHub和GitLab的代码；
一键部署，完全可视化的pipeline配置，拖拽方式的pipeline搭建；
阶段式和阶梯式pipeline，可自由扩展的步骤系统；
灵活的流程控制：不同的代码分支可以自动匹配不同的CI流程，从而支持较为复杂的流程控制
支持多种触发方式：计划任务的触发、来自GitHub / GitLab的webhook触发、手动触发，以及通过定制化的开发，实现更多种触发方式的支持
良好集成的审批系统：审批系统已与Rancher用户管理系统集成，且用户可以在任意阶段插入断点，自由地对任意阶段进行审批
灵活的pipeline启停机制：任一环节出错，整个进度可以立即停止，而问题解决之后又可以重新运行

4、工作流

集中式工作流是集中式版本控制工具中常用的开发流程，以主分支(mater)为核心，所有开发人员通过更新主分支代码完成代码的开发工作。

工作流程是这样的：

• 现在团队里面有两个人，子旺和金康，他们两个人分别克隆了远程的仓库gitdemo
• 现在子旺进行了一次提交，远程仓库就多了一个版本的提交git push orgin master
• 现在金康想要提交到远程仓库，发现没办法提交push，需要先git pull --rebase origin master 拉取的时候，同时进行变基操作，保证代码版本历史的漂亮（当然这种漂亮有时候也需要付出一些代价）
• 总的来说，集中式的工作流，就需要不断拉取远程仓库和本地的进行同步，即push前需要先pull。（不断的pull是非常友好的，也是公司开发需要的）

功能开发工作流

功能分支工作流以集中式工作流为基础，不同的是为各个新功能分配一个专门的分支来开发。这样可以在把新功能集成到正式项目前，用Pull Requests的方式讨论变更。pull requests工作流能为每个分支发起一个讨论，在分支合入正式项目之前，给其它开发者有表示赞同的机会。

工作流程是这样的：

• 团队里面的子旺在master分支上开了一个功能分支feature-xxx，现在子旺饿了，要去吃点东西，在去之前要把编写的代码提交push git push -u origin feature-xxx（-u选项设置本地分支去跟踪远程对应的分支）到远程的feature-xxx分支上面。
• 现在子旺完成了功能开发，并且push到他的远程分支feature-xxx，他发起一个Pull Request让团队的其它人知道功能已经完成。
• 现在金康变成了领导，领导收到了子旺发来的pull request，金康对工作有些不满意，所以让子旺进行修改，这些修改对话都是在pull request上完成的。终于，金康接受了pull request进行了merge，金康在合并前一定要检出master分支并确认是它是最新的，这样才可以合并到master上。

Gitflow工作流

• 相对于使用仅有的一个master分支，Gitflow工作流使用两个分支来记录项目的历史。master分支存储了正式发布的历史，而develop分支作为功能的集成分支。
• 每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。但功能分支不是从master分支上拉出新分支，而是使用develop分支作为父分支。
• 一旦develop分支上有了做一次发布的功能，就从develop分支上checkout一个发布release分支。 新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上-----这个分支只应该做Bug修复、文档生成和其它面向发布任务。 一旦对外发布的工作都完成了，发布release分支合并到master分支并分配一个版本号打好Tag。 另外，这些从新建发布分支以来的做的修改要合并回develop分支。
• 维护分支或说是热修复（hotfix）分支用于给产品发布版本快速生成补丁，这是唯一可以直接从master分支fork出来的分支。 修复完成，修改应该马上合并回master分支和develop分支（当前的发布分支），master分支应该用新的版本号打好Tag。

Forking工作流

Forking工作流和前面讨论的几种工作流有根本的不同，这种工作流不是使用单个服务端仓库作为『中央』代码基线，而让各个开发者都有一个服务端仓库。这意味着各个代码贡献者有2个Git仓库而不是1个：一个本地私有的，另一个服务端公开的。

工作流程是这样的：

• 团队里面的金康出去创业了，开了一家新公司，但是子旺舍不得金康，所以还在帮助金康开发，现在金康初识化了一个仓库，并进行了一些提交，自己在玩。
• 子旺是一个好心人，想帮助金康做一些贡献，因此子旺fork了金康的项目，此时子旺需要在自己的仓库中开设2个远程别名 —— 一个指向正式仓库（金康的仓库），另一个指向开发者自己的服务端仓库（子旺的仓库）。这样做的目的是为了能够拉取金康的仓库更新。代码如下：

# 给金康的仓库起了一个远程别名 upstream
git remote add upstream https://github/guojinkang/gitdemo
git pull upstream master

• 子旺完成了功能的开发，准备合并到金康的库上，需要先进行一个pull request，他想集成他的功能分支到上游远程仓库的master分支中
• 金康收到了pull request，金康此时要检查子旺的代码是否可以合并 git fetch https://github/fuziwang/gitdemo feature-branch 发现可以合并，因此进行合并。
• 此时子旺需要拉取最新的代码 git pull upstream master