git是程序员们日常使用的一个版本管理工具；

github是世界上最大的程序员集散中心，负责代码托管和程序员的日常交流。

在准备参与一个开源项目的开发之前，我们需要了解一些基础知识。

（其实很讨厌写这些废话，一个程序员谁不知道 git 和 github 呢？要你说这些口水话？但是文章开头不写点废话又不知道写点什么，以后看多写写能不能整点大家喜欢的废话给你们看看,其实写这篇文章的主要原因是因为年少轻狂不懂事进了一个开源项目的开发群，一开始也学人装逼，聊着聊着发现里面个个都是人才，说话又好听，那我自己呢，vue3 又不 6，代码水平没有大佬那么丝滑。然后就只能写一写 git 的操作文档，才能维持得了生活这样子。最主要是让一些不会提 PR 的人（一周之前的我自己）提提 PR，搞搞人气，点点 star，这样我才能在吸引更多人来群里，我自己就不会显得那么的菜逼~ 我可真是个小机灵鬼!）

git基础知识准备

基础名词

branch

顾名思义-分支，git中的分支是一个很重要的概念， 首先可以使用git branch -a指令查看当前项目的所有分支

在实际开发中经常需要从主分支切到开发分支，或者以当前分支为模板创建并切换到另外一个新分支。

    git checkout dev // 切换到dev分支
    git checkout -b dev//已当前分支为模板创建dev分支并切换过去

当你在dev分支开发完成新需求或者修复完bug之后，需要将dev中的代码和master分支上进行合并的时候，就涉及到了分支合并的操作，分支合并通常有下面的两种方法： git merge:

    git merge dev //分支切换到master之后，用git merge去合并dev

这里重点说一下第二种方法git rebase

git rebase实际上就是取出一系列提交记录，然后放到目标分支上去，不同于merge的是，通过git rebase合并的代码提交历史会是完整的一条线，而不是群魔乱舞的各种分支互相纠缠，所以现在大家都推荐用git rebase进行分支操作。

这里我们用实际例子来展示一下整个rebase的过程：

首先我们在master分支和dev分支上各修改并提交一个文件，且修改同一个地方让合并的时候有冲突，如图所示： （这里强烈建议刚学git的小伙伴去下载一个git的图形工具，我这里用的是sourcetree，你们搜一搜下载就好了）

具体使用方法如下：

git rebase master //在dev分支开发完成提交之后切换到master分支

这个时候如果有冲突的话就会显示如下提示： 修复冲突，然后执行如下操作：

git add //把修复的文件重新add一下
git rebase --continue//继续进行rebase合并

操作完成后我们发现，现在dev和master在一条线上了

随后我们切换到master分支上，再次使用git rebase dev,让master分支和dev分支合并，最后再进行push操作，操作结束后视图长这个样子。

(一家人就是要整整齐齐)

放一张使用merge操作之后的视图，有对比才有杀伤力

对于分支的操作还有很多，比如说使用git reset --hard去做回滚，用git revert去回滚，用git cherry-pick或者git rebase -i去做提交挑选和合并，又或者是用git commit -amend做提交信息补充等等一系列操作 就不在文章里细说，这些操作都可以在 强烈强烈强烈强烈强烈强烈推荐每个人都去过一遍的git操作小游戏 里面自己过一遍，过完一遍收益匪浅!

你数一下我用了多少个强烈去推荐这个好网址，由浅入深的用小游戏闯关的方式让你去学习git的常用和进阶操作，我家的猫看完都直呼靠谱！

Issue

Issue是一个对任务和问题分配进行追踪和管理的功能，在我们提交PullRequest的时候，都会同时创建一个Issue，它们共用一个ID。在commit代码时，可以在提交信息中和Issue进行交互。

首先我们创建一个Issue

我们在commit的时候的提交信息中和该Issue交互

成功commit之后我们可以在对应的Issue中找到此次提交的代码记录

我们还可以尝试一下其他类型的交互，比如说通过指令关闭Issue

关于github中的Issue我们就了解到这里，接下来我们来看看其他参与开源项目中需要用都的一些基础操作指令吧~

基础操作指令

### git fetch

### git rebase

### git merge

git pull

这里就有人问了:"诶，你前面都画叉叉了这个怎么不叉掉呢，你写了个小标题又不写内容你这不是忽悠人嘛!"

其实git pull 操作是前面集中操作的组合技，我们日常使用的常用的pull指令有以下两种：

git pull = git fetch + git merge
git pull --rebase = git fetch +git rebase

git fetch指令可以把远程仓库中的最新代码拉取到本地，一般fetch下来之后分支的情况类似于这样：

我们通过git fetch把C提交拉取到本地后，可以通过git merge或者git rebase去把当前dev分支合并到最新的C节点上，两者的区别在上面已经说过了，这里就不再赘述。

给一个开源库提一个pullrequest（PR）

首先我们需要知道什么是pullrequest,PullRequest是自己修改源代码后，请求对方仓库采纳该修改的一种行为。PullRequest发送后，目标仓库的管理员可以查看PullRequest和你更改的代码，同时大家可以对你的此次提交添加评论。

1. Fork需要参与的项目仓库

2. 在自己的repositories中将代码clone下来

选择https或者ssh方式都可以，取决于你是否在本地配置了密钥 代码拉取到本地之后，就可以根据自己的知识储备去阅读代码中的大致结构和使用的技术栈，遇到不懂的就可以去群里找大佬问，对项目了解的差不多的时候，就可以尝试自己的人生中的第一个pr了。

第一步 设置上游分支

git remote add upstream xxxxxx.git

成功设置之后可以用git branch -a来查看所有关联的分支

设置上游分支的目的是为了能够在本地直接去拉取上游仓库的代码，从而使本地的代码和上游仓库保持最新。这里有人可能对上游分支，远程分支，本地分支概念有点理解不清楚，可以看看下面这张图。

（灵魂画手献丑了）

我们设置的上游仓库其实是项目拥有者或者说项目创建者的仓库地址，在每次进行开发之前，使用下面指令拉取上游分支最新代码。

第二步 拉取上游分支最新代码

git pull --rebase upstream 分支名

从sourcetree可以看到距离我上一次向上游代码提交PR后，上游仓库已经有很多次提交了，执行了git pull之后，本地的代码和远程分支不同步，接下来我们要用本地的分支去强制更新一下远程分支。执行git push -f指令去强制更新远程仓库，更新之后，分支情况如下：

这时，所有的分支都是最新的，可以愉快的进行需求开发了。当然实际开发中一般会在本地多切一个分支来进行需求的开发或者bug的修复，一般我们称之为特性分支，这样我们就可以在开发需求的同时，保证有一个可以发布软件的稳定分支，通常是叫master,这样做有很多好处，在用特性分支进行Pull Request的时候，可以拥有更明确的主题，让对方知道你修改代码的意图，有助于提高代码审查的效率。

第三步 写点什么

略(此处省略一万步)

第四步 发起一个Pull Request

之后来到我们的git上，发起一个Pull Request

在comparechange阶段可以查看这次的PR中你提交了些啥东西，点开很直观的看到文件对比，确认无误后就可以创建一个PR

在提交标题和内容中进行编辑，不同的开源库有不同的编辑格式，说清楚提交的意图，方便owner进行审核。

接下来可以进入对应的PR和大家进行讨论，让大家看看你写的代码是否有漏洞或者不妥的地方

之后owner审核通过之后，就完成了一个PR的全流程了~ 完结撒花

注意事项

• 在提交的时候，有些项目会对commit的提交信息有格式限制，可以在对应项目的 package.json 中查找对应的配置规范，比如：

我提交的这个项目中配置了commit-msg,一般可以在commitlint.config.js文件中查看对应的规则，如果不按照规则提交，那么commit会报错并且阻止提交。

• 一些仓库对于提交的commit message会有额外的要求，比如说在commit message中不能出现merge的信息，或者甚至说一个需求最好只有一个commit message。这个时候我们可以借助git rebase -i或者git commit --amend帮我们进行commit的合并。有需求的可以自己去查看一下git rebase -i指令，对一些有git log洁癖的人或者强迫症晚期患者真的很有用。
• 提交PR并不是说一定要等到所有东西都开发完才可以提交，实际开发过程中，如果等所有功能开发完成后再去提pr,很可能导致在接受设计和实现方面的指正之后，需要大规模的修改甚至重新实现。我们可以早点的提交PR，在代码开发过程中让团队成员加入讨论进来。为了防止这种开发过程中的PR被误合并，可以在标题中填写一些团队约定的名字，比如'ing''wip'等来进行区分。
• git的相关知识还有很多，包括一些hub指令，Travis CI等周边配套插件的使用。现在暂时没有需求，大家等有需求的时候可以再去找相关的资料看一看也不迟。

小声BB几句

前段时间总会感慨，前端要学的东西好多呀！vue2 还没学透，vue3 就出了！React Fiber 都没整明白，React18 就要出了！还有一些服务器端的 Node，Node 上面又有框架，还有混合开发，小程序的语言，然后他们的原生上面又有框架，框架上面还有框架！有时候去面试，面试还要考 http，网络安全，算法，乱七八杂一大堆！

但是静下心来想一想，回望自己工作的几年的工作生涯，有几点思考，想和大家分享一下：

1.有些东西你真的需要学习吗？有些技术栈值不值得你投入过多的时间成本去学习吗？ 前端变化很快，技术更迭也很快，有些东西还没等你去了解就已经默默的被淘汰了，真正学完之后终身受用的应该是那些基础 用前端领域的一些名词来描述所谓的基础，我想就是js，css,html,计算机网络,算法等等，换句话说，就是组成前端这座大厦的砖块。而框架是用这些砖块搭建起来的一个小屋子，在学习的时候，我们不能只专注在API的层次学一个框架，你要学的是这个框架用了哪些砖块,用了什么方式把这个砖块组合在了一起，我认为，这个才是重要的东西，才是值得我们花时间学习的东西！

2. 前段时间看到一个公众号上写了一个关于前端程序员的故事，我觉得很受用，这里贴一下他说的结论：

有限的时间，尽可能尝试。不要给自己设限

你选择的身份很重要，你的职业成功最终将不是你现在所知道的东西来定义,而是由你在40年或更长时间内能够学到的东西来定义

我觉得说的非常的有道理，生活在这么一个标签化的时代，程序员这个标签就已经很多梗了，咱就不要再给自己贴前端程序员，React程序员，小程序开发程序员等等这些标签了，不要认为的限制自己，先把思想放开，格局才能大！（脑子里自动浮现出了一些表情包，贴出来给大家看看）

3. 内卷，我觉得内卷这个现象一直都在，只是突然有了一个词可以精准的描述出来这现象，以前叫竞争压力大，但是这种描述是五个字的，听起来就有点拖沓，有点不到位。直到内卷这个词出来，大家就觉着有点意思，然后和躺平一起活跃在打工人各种社区中。我觉着人还是得跟自己比有意思，我称之为自来卷 （salute 自来也）。每天问问自己：'你今天变得更博学了吗？答案如果是yes，很好，你变强了，答案如果是no，那也没事，你只是输给了昨天的自己！如果你能把自来卷玩的熟练，还怕什么内卷呢？你们卷你们的，我卷我自己的就好！

4 没有第四点了，一篇写git操作的文章写这么多屁话也不知道自己在想些啥。这要是搁考试里面作文题，这种行文已经跑题零分了。不说了，把这篇文章引用的文章和相关项目放下面，感兴趣的自己看看。

1.varlet-一个vue3开发的组件库。

2.GitHub入门与实践这里放一个图书的链接，需要的同学可以自己找电子版或者购买纸质书。