🍯踏出第一步，在 Github 上规范的提交 PR
🍯踏出第一步，在 Github 上规范的提交 PR
最近参与朋友的一个关于收集国内免费ChatGPT镜像，prompt，以及其他AI应用等的Github项目，正好比较适合新手熟悉在 Github 上规范的提交 PR的流程，那看看我是怎么做的吧！
🍻找项目
比如这个收集国内免费ChatGPT镜像，prompt，以及其他AI应用的 GitHub - Tptogiar/AI-Collection
当找到一个项目的时候，你可以先看看有没有人在 issue 和 PR 中，有没有人已经提出过与你观点相同和相近的反馈意见或修改提交。注意作者是怎么回复的，避免浪费自己时间。
如果发现了小问题，而且自己的时间有限，就可以先提一个issue，提醒作者或者其他人解决，如果没有人回应，再尝试自己提交PR。
所以，怎么提交？
🍻派生一个存储库 (Forking a repository)
进入项目主页，点击Fork按钮，创建一个新的派生项目（Create a new fork）
设置好仓库名称以及Description后，再点击Create fork按钮，创建派生项目到自己工作区
🍻克隆一个派生（Clong a fork）
进入自己的Github工作区，将派生项目克隆到本地（或者远端服务器）
# 克隆项目到本地（注意是派生项目的连接，而不是原始项目）
git clone 你的派生项目地址
🍻创建一个分支（Create a branch）
# 创建并切换到本地分支，分支的命名尽量简洁且见名知意（与解决的问题相关）
git checkout -b 分支名
🍻做出修改（Make changes）
针对你发现的问题在对应的地方修改😋
🍻提交修改 (Pushing changes)
这步需要注意一下，有些项目更新的会比较频繁。当你做出修改和提交 PR 之前，可能有作者新的提交和 PR 被合并到原项目。如果有这种情况发生，在你工作区的派生项目会显示原项目有更新。
所以你应该点击Update branch之后，将原项目更新同步到派生项目，再进入本地项目文件夹
# 当前文件夹位置
# 保存本地修改并将工作目录还原到当前HEAD提交状态
git stash
# 从远程拉取最新的项目代码，将派生项目更新同步到本地
git pull
# 将保存的修改还原回当前工作目录
git stash pop
查看更新后的内容是否和本地修改有冲突，如果有就解决冲突，完成后就可以提交修改了
# 当前文件夹位置
# 保存本地修改并将工作目录还原到当前HEAD提交状态
git commit -am '改动内容的描述'
# 推到派生项目远端仓库，因为之前项目分支是在本地创建的，需要带上 '--set-upstream'
git push --set-upstream origin 分支名
🍻创建合并请求 (Create a pull request)
回到线上派生项目的工作区，会看到新分支和修改的合并提交信息，点击Compare & pull request
🔸选择你想并入的原项目分支，标题和描述信息。如果有对应的 issue，就通过键入 # 添加(Github 会自动展示 issues 列表)
🔸点击 Create pull request ，就行了。
🍻发表评论 (Address review comments)
这种得看原项目作者要遵循的规范😋
🍻合并你的请求 (Merge your pull request)
原作者要做的事情😋
🍻删除你的分支 (Delete your branch)
最后一步不是必须的，只是保持一个规范的开源协作习惯，减少意外提交错误项目分支的情况发生。
来到原项目 Github 主页，找到之前已经合并的提交请求（在关闭的 PR 列表中），点击 Delete branch
# 删除本地分支
git branch -d 分支名
#其他相关指令
# 删除远程分支
git push origin -d 分支名
# 清理本地不存在的远程分支，如别人删除了dev，但是你本地查看还有，就可以执行该条命令
注意：下次在已有的派生项目创建新分支前，要先将原项目的更新同步到派生项目，并将更新后的派生项目拉到（git pull）本地，再重新建立分支（git checkout -b new-branch-name ），再重复上述过程即可。
🍯git相关指令
🍻 git stash
🔸用来临时存一下不想被提交的代码变更的
🔸常用命令
git stash save 'xxx'：存储变更
git stash list: 查看储存区所有提交列表
git stash pop: 弹出并应用最近的一次储存区的代码提交
git stash drop stash@{n}: 删除某次储存记录
git stash clear: 清楚所有 stash 信息
它的数据将被存在你仓库 .git 文件下的 refs/stash 里。
🍻 git clone
🔸用来克隆仓库，将仓库代码拉到本地
🔸常用命令
git clone xxx.git: 拉取代码，默认留在master分支
🍻 git init
除了直接从远端建立仓库之外，我们本地也是可以自己初始化一个Git仓库的，使用git init就可以为当前目录创建一个git仓库，就可以开始对当前目录的改动纳入版本管理库了
不过本地init的仓库没法跟远端的进行交互，所以我们还得去github等创建一个远端仓库，然后关联：git remote
🍻 git remote
🔸用于和远程仓库进行关系绑定处理等等
🔸常用命令
git remote add: 添加一个远程版本库关联
git remote rm: 删除某个远程版本库关联
比如我们本地有一个初始化完的仓库，同时远程也有一个空仓库，就可以让他们关联起来
git remote add origin xxx.git先添加到本地仓库
git push -u origin master：表示把当前仓库的 master 分支和远端仓库的 master 分支关联起来，后面我们执行 push 或者 pull 都可以非常方便的进行操作了。
🍻 git branch
🔸用于查看分支
在拿到一个项目之后，你首先还是应该看一下当前仓库现在有哪些分支，不要待会创建新分支发现名字重复之类的问题
🔸常用命令
git branch：查看本地所有分支信息
git branch -r：查看远程仓库所有分支
git branch -a：查看本地和远程仓库所有分支
一般来说如果分支太多的话，还是建议使用可视化工具来查看分支信息，比如 vscode 或者 source tree 等软件等等。
🍻 git checkout
🔸以当前分支为基准，创建一个新的分支并切换过去
🔸常用命令
git checkout -b branch1：创建并切换到指定新分支：
🍻 git add
🔸用于修改完，添加文件到暂存区
🔸常用命令
git add .：把当前目录下得所有文件改动都添加到暂存区
git add -A：把当前仓库内所有文件改动都添加到暂存区
🍻 git commit
🔸将暂存区的内容提交到本地 git 版本仓库中
git commit [file1] ... -m [message]-m 表示的是当前提交的信息
-a 对于已经被纳入 git 管理的文件（该文件你之前提交过 commit），那么这个命令就相当于帮你执行了上述
git add -A，你就不用再 add 一下了；对于未被 git 管理过的（也就是新增的文件），那么还是需要你先执行一下git add -A，才能正确被 commit 到本地 git 库。
🔸常用命令
git commit -m 'feat: do something'：设置当前提交的信息
git commit -am：add+commit
🍻 git rm
🔸比如我们项目中有个文件叫 .env，这个文件是一个私有的，不能被提交到远程的，但是我们不小心提交到了本地仓库中，这个时候我们把这个文件添加到 .gitignore 文件中，表示需要被 git 忽略提交，但是由于我们已经提交到本地仓库了，所以如果不先从 git 仓库删除是没用的。
如果直接右键删除，那么这个文件的记录还是会被保存到远端仓库，别人还是能看得到你这个信息，所以我们需要先从 git 仓库中删掉这个文件才行。
🔸常用命令
git rm .env：执行完这个命令就表示 .env 文件从 git 仓库中删除了，配合 .gitignore 就能保证以后所有的 .env 文件变更都不用担心被提交到远程仓库。
git rm -r dist：如果我们要删除的是一个目录，那么加上 -r 参数就好了。
🍻 git push
🔸想要把刚创建好得分支推送到远端，一般来说我们可能会需要用到 git push，但我们这是个新分支，根本没和远端仓库建立任何联系，那么我们就需要加点参数，让他们关联上：
🔸常用命令
git push --set-upstream origin branch1：推送分支并建立关联关系
但是这里需要注意，如果远端仓库已经有了这个分支名怎么办？
- 一种就是你本地的代码和远端代码没有冲突的情况下，并且你本地有新增提交，那么你可以仍然执行上述命令，这样就会直接将当前本地分支合远程分支关联上，同时把你的改动提交上去。
- 本地分支和远端分支存在冲突，这个时候你执行上述命令就会出现提示冲突，那么接下来就需要你先把远端当前分支的代码拉下来，解决一下冲突了，就需要用到 git pull 命令了。
🍻 git pull
🔸如果当前分支已经和远端分支建立了联系，那么合并远端分支只需要执行 git pull ，不用带其他参数，但如果和上面提到的 git push 时产生了冲突，还没有建立联系的时候，我们就需要指定需要拉取哪个分支的代码下来进行合并。
🔸常用命令
git pull origin branch1：拉取指定远端分支合并到本地当前分支
回到上面提到的冲突问题，我们可以直接使用 git pull 然后指定合并当前本地分支想要建立联系的远程分支，然后本地解决一下冲突，然后提交一下改动，再执行 git push --set-upstream origin branch1 命令就大功告成了。
🍻 git fetch
特定时候想把远端仓库对应分支的变更拉到本地，并不想自动合并到工作区（你当前正在进行代码变更的工作区），等晚些时候写完了某部分的代码之后再考虑合并，那么就可以先使用 git fetch。
fetch 完毕之后，我提交了自己当前工作去的变更到本地仓库，然后想合并一下远端分支的更改，这个时候执行一下 git merge origin/[当前分支名]（默认一般是用 origin 表示远端的分支前缀）即可。
🍻 git log
🔸看到当前分支的提交记录信息，可用于后续代码版本回滚等
🍻 git reset
🔸回退版本
git reset [--soft | --mixed | --hard] [HEAD]
关于HEAD:
HEAD 表示当前版本
HEAD^ 上一个版本
HEAD^^ 上上一个版本
HEAD^^^ 上上上一个版本
HEAD~n 回撤 n 个版本，这种也是更加方便的
参数解析：
以下解析均基于后接参数为 HEAD^，也就是git reset HEAD^。
--soft: 重置你最新一次提交版本，不会修改你的暂存区和工作区。
--mixed: 默认参数，用于重置暂存区的文件与上一次的提交(commit)保持一致，工作区文件内容保持不变。
--hard: 重置所有提交到上一个版本，并且修改你的工作区，会彻底回到上一个提交版本，在代码中看不到当前提交的代码，也就是你的工作区改动也被干掉了。
🍻 git reflog
🔸用来查看你的所有操作记录。
既然 git log 看不到之前 commitId 了，那么就回到 reset 之前的状态
PS D:\Code\git-practice> git revert 3b18a20ad39eea5264b52f0878efcb4f836931ce
On branch branch2
Your branch is ahead of 'origin/branch2' by 1 commit.
(use "git push" to publish your local commits)
这个时候，它会提示你可以把新的改动 push 上去了。
其实你如果在 gitlab 进行 mr 之后，想要回滚这个 mr，一般它会给你一个 revert 的按钮选项，让你进行更安全的回滚操作
🍻 git revert
如果针对master的操作，为了安全起见，一般还是建议使用revert命令，也能实现和reset一样的效果。
🔸git revert & git reset
reset 是向后的，而 revert 是向前的
也就是说，reset会带你回到没有犯错之前，而revert会给你一个弥补方案，采用这个方案后会让你得到的结果和没犯错之前一样，相当于是一个互补的操作。
如果你不想之前那个提交消失在当前历史当中，那么你就可以选择使用 git revert [commitId]，那么它就会产生一次新的提交，提交的内容就是帮你复原你上面改动的内容。
🍻 git cherry-pick
如果忘记切分支，然后在 master 分支上改了代码，并且提交到了本地仓库中，这个时候可以使用git cherry-pick。
🔸git cherry-pick：将执行分支的指定提交合并到当前分支
比如我在 master 分支提交了某个需求的代码，同时还没提交到远程分支，那么你就可以先 git log 查看一下当前的提交，找到 master 分支正常提交之后的所有 commitId，然后复制出来，然后再切到你建好的开发分支，接着执行 git cherry-pick master commitId1 commitId2 commitId4。
完事之后记得清理一下作案现场，把你的 master 分支代码恢复到正常的提交上去。
更具体的内容请参考：www.ruanyifeng.com/blog/2020/0…
🍻 git tag
一般可能会在你发布了某个版本，需要给当前版本打个标签。
vite 的官方 git 仓库，查看它的 tag 信息，就标注了各个版本发布时候的 tag 标签
它有两种标签形式，一种是轻量标签，另一种是附注标签。
🍶轻量标签
🔸创建方式：git tag v1.0.0
有点像对某个提交的引用，但是从表现形式上有点像基于当前分支提交给你创建一个不可变的分支，支持你直接checkout到这个分支，但是和普通的分支有本质区别。
如果你切换到了这个 tag "分支"，你去修改代码同时产生了一次提交，亦或者是 reset 版本，这对于该 tag 本身不会有任何影响，而是为你生成了一个独立的提交，但是却在你的分支历史中是找不到的，你只能通过 commitId 来切换到本次提交。
那如果你从其他分支通过 commitId 切换到这个改动上，它会提示你以下内容：
Note: switching to 'be276009'.
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:
git switch -c <new-branch-name>
Or undo this operation with:
git switch -
也就是可以选择丢弃或者保留当前更改，如果需要保留的话直接使用下面的 git switch 命令创建一个新分支即可。
🍶附注标签
从概念上看，轻量标签更像是一个临时的标签，而附注标签更加正式一点，能够保留更多的信息。它创建的方式和轻量标签区别主要是 -a 和 -m 参数，如果你的 -m 参数不传，那么编辑器会让你手动填写。
来自官方：
而附注标签是存储在 Git 数据库中的一个完整对象， 它们是可以被校验的，其中包含打标签者的名字、电子邮件地址、日期时间， 此外还有一个标签信息，并且可以使用 GNU Privacy Guard （GPG）签名并验证。
🔸创建方式：git tag -a v1.0.1 -m "发布正式版 1.0.1"
🔸其他命令
git show：查看标签最终体现的信息
- 轻量标签
- 附注标签
从信息丰富度上来说，附注标签能保留的信息会更多。
git push origin tagName：推送标签
git tag：查看标签
git tag -l v1.0.1：筛选标签
git tag -d v1.0.1：删除标签
git push origin --delete v1.0.2：删除远程标签
git push origin :refs/tags/v1.0.1：另一种删除远程方式（表示将“:”前面空值替换到远程，也不失为一种方式）
🍻 git merge
🔸合并指定分支代码到当前分支。
一般来说，我们用的比较多的场景可能是，远端仓库 master 分支有变更了，同时这个时候我们准备提 MR 了，那么就需要先合一下 master 的代码，有冲突就解决下冲突，那这个时候我们可以做以下操作：
- 切到
master分支，git pull拉一下最新代码 - 切回开发分支，执行
git merge master合并一下 master 代码
🍻 git rebase
🔸分支合并 || 整理你的提交历史。
分支合并
rebase & merge都可以合并分支，但是merge会多出一条合并的提交记录和分支合并线，如果有很多分支合并的话，会显得杂不是很清晰。
rebase 是重置基线的意思，代码提交记录清晰，特别是大项目团队开发时，使用merge有时会将别人提交的代码合并后和自己的代码一起提交，甚至在一个提交线上夹杂着多个用户的提交，不利于代码审查，使用rebase 则可以解决这个问题，让你的代码提交集中于一次，利于代码审查，提交记录清晰明了。
提交历史整理
除了分支合并之外，rebase 还可以整理一下历史的提交记录，比如你开发完了一个需求，做这个需求过程中产生了很多次的提交，这些提交里有的 commit 信息写的太简略，有的 commit 根本是测试的，没啥保留的必要，想合到某一个相近的历史提交中就好了，还有就是某个提交没啥用，想删了，对于这些诉求，我们就可以利用 rebase 来进行改造了。
最后，在了解了这些操作后，快点踏出你的第一步吧！！