更新内容，请直接看这里

这是工作/团队协作中最常见的一个基本流程，可以跟着这一串自己试一试。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# 最开始
$ git clone					#将远程仓库的代码拉到本地(local-git)
# 记得切换新分支哦！
$ git checkout -b 分支名	  #创建新的分支，并在该分支下工作（例:git checkout mybranch）

# 写完一些东西，想更新一下仓库时
$ git add --all或git add .  #添加等待commit
$ git commit -m "XXX"   	#放进local-git里(“附加信息”，一般就"update from XXX")

# commit之后
$ git checkout main			#先切换到主分支
$ git pull origin main		#把远端main同步到local_main中
$ git checkout raliz		#切换到自己的分支
$ git rebase/merge main	    #将自己分支的代码和主分支上的新代码合并
# 这里可能需要手动解决rebase conflict，看一下自己的编译器，操作一下
$ git add --all 或 .
$ git commit -m "msg"
$ git rebase cotinue
$ git push (-f) origin 分支名  #(强行)push，将合并后的分支推送到远程仓库的对应分支
# 去pull request，添加分支合并
# squash and merge，delete分支

# 等待远端更新完毕
$ git checkout main			#切换到主分支
$ git branch -D 分支名	  	  #删除自己创建的分支
$ git pull origin main		#拉取船新版本
$ git checkout -b raliz		#创建新分支，并在该分支下工作

你可能发现了，git rebase 和 git merge都能合并分支，但你知道两种的区别嘛？

git merge main 和 git rebase main的区别

merge

merge会在feature分支中新增一个新的merge commit，然后将两个分支的历史联系在一起。

是一种非破坏性的操作，对现有的分支不会造成任何方式的改变。

分支每次需要合并上游更改时，它都产生一个额外的和并提交。

如果main分支提交十分活跃，那么可能会严重污染feature分支记录，可以使用git log来解决。

git-merge

rebase

rebase会将整个feature分支移动到main分支的顶端，有效整合了所有main分支的提交。

rebase通过为原始分支中每个提交创建全新commits来重写项目历史记录。

rebase能使得获得更清晰的项目历史，消除了git merge那样不必要的和并提交。

git-rebase

image-20230720203517949image-20230720203413810

rebase rebase feature，等效与创建了新提交，且老的提交只是不能再被访问使用

GitHub工作流学习实践总结

这个工作流是跟着一超级牛牛up主学的，比较规范。

下面的内容

更适合开源项目

更适合开源项目

更适合开源项目

fork

fork-分叉，是在github账户上完成的。

fork一个存储库，会在我们的GitHub账户上创建一个原始存储库的副本。

对分叉存储库所做的更改，可以通过一个pull请求与原始存储库合并。

fork只包含存储库的一个单独副本，不涉及命令。

必要性

  • 一些项目仓库在安全设置上会禁止直接在主仓库直接push——在参与开源项目代码贡献时，通常不会直接获得源代码仓库的Developer权限。这点和一般公司开发不太一样，公司一般都是设置在分支上是否有Push权限。
  • 自己修改一些东西不会影响到主仓库，而且比较安全合理，很巧妙啊。

相关操作

fork一下

image-20230218103127303

这样子就在自己账号下生成分仓库力！

image-20230218103208307

同步一下

查了很多地方，百度搜出来的最不靠谱，官方文档最靠谱↓

https://docs.github.com/zh/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

在WebUI同步分叉分支

  1. 在 GitHub 上，导航到您想要与上游版本库同步的复刻仓库主页。

  2. 选择“同步分支”下拉菜单。

    突出显示“同步分支”下拉菜单

  3. 查看有关上游存储库提交的详细信息，然后单击“更新分支”。突出显示“更新分支”按钮的同步分支模式

如果上游仓库的更改导致冲突，GitHub 将提示您创建拉取请求以解决冲突。

从命令行同步分叉分支

  1. 打开Git Bash。

  2. 将当前工作目录更改为您的本地仓库。

  3. 从上游仓库获取分支及其各自的提交。 对 BRANCHNAME 的提交将保存在本地分支 upstream/BRANCHNAME 中。

    1
    2
    3
    4
    5
    6
    7
    $ git fetch upstream
    > remote: Counting objects: 75, done.
    > remote: Compressing objects: 100% (53/53), done.
    > remote: Total 62 (delta 27), reused 44 (delta 9)
    > Unpacking objects: 100% (62/62), done.
    > From https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY
    >  * [new branch]      main     -> upstream/main

  4. 签出分支的本地默认分支，在本例中，我们使用 main。

    1
    2
    $ git checkout main
    > Switched to branch 'main'

  5. 将上游默认分支（在本例中为 upstream/main）的更改合并到本地默认分支中。 这会使复刻的默认分支与上游仓库同步，而不会丢失本地更改。

    1
    2
    3
    4
    5
    6
    7
    8
    $ git merge upstream/main
    > Updating a422352..5fdff0f
    > Fast-forward
    >  README                    |    9 -------
    >  README.md                 |    7 ++++++
    >  2 files changed, 7 insertions(+), 9 deletions(-)
    >  delete mode 100644 README
    >  create mode 100644 README.md

    如果本地分支没有任何唯一提交，Git 将执行快速转发。 有关详细信息，请参阅 Git 文档中的基本分支和合并。

    1
    2
    3
    4
    5
    $ git merge upstream/main
    > Updating 34e91da..16c56ad
    > Fast-forward
    >  README.md                 |    5 +++--
    >  1 file changed, 3 insertions(+), 2 deletions(-)

    如果本地分支具有唯一提交，则可能需要解决冲突。

继续开发

这样子就能保证项目基本开发线性啦

pr基本流程

在for不fork的基础上↓

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# 最开始
$ git clone					#将远程仓库的代码拉到本地(local-git)
# 记得切换新分支哦！
$ git checkout -b 分支名	  #创建新的分支，并在该分支下工作（例:git checkout mybranch）

# 写完一些东西，想更新一下仓库时
$ git add --all或git add .  #添加等待commit
$ git commit -m "XXX"   	#放进local-git里(“附加信息”，一般就"update from XXX")

# commit之后
$ git checkout main			#先切换到主分支
$ git pull origin main		#把远端main同步到local_main中
$ git checkout raliz		#切换到自己的分支
$ git rebase/merge main	    #将自己分支的代码和主分支上的新代码合并
# 这里可能需要手动解决rebase conflict，看一下自己的编译器，操作一下
$ git add --all 或 .
$ git commit -m "msg"
$ git rebase cotinue
$ git push (-f) origin 分支名  #(强行)push，将合并后的分支推送到远程仓库的对应分支
# 去pull request，添加分支合并
# squash and merge，delete分支

# 等待远端更新完毕
$ git checkout main			#切换到主分支
$ git branch -D 分支名	  	  #删除自己创建的分支
$ git pull origin main		#拉取船新版本
$ git checkout -b raliz		#创建新分支，并在该分支下工作

牛牛！！

commite message

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
<type>: <subject>

type(必须)——用于说明git commit的类别，只允许使用下面的标识。
feat：新功能（feature）。
fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。
fix：产生diff并自动修复此问题。适合于一次提交直接修复问题
to：只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix
docs：文档（documentation）。
style：格式（不影响代码运行的变动）。
refactor：重构（即不是新增功能，也不是修改bug的代码变动）。
perf：优化相关，比如提升性能、体验。
test：增加测试。
chore：构建过程或辅助工具的变动。
revert：回滚到上一个版本。
merge：代码合并。
sync：同步主线或分支的Bug。

示例：
feat: 添加 button 组件
fix: 修复 button 组件 circle 样式
refactor(docs): 添加input文档

常用命令行

1
2
3
4
5
6
7
$ git branch		#查看本地所有分支
$ git branch -m oldName newName		#更改分支名
$ git remote -v		#查看本地关联地址
$ git remote remove origin		#删除现在关远程仓库
$ git remote add origin XXX		#添加新的远程仓库

$ git rebase --abort		#取消rebase

注意事项

提交pr过程中要注意这些问题，不然自己都会嫌弃自己。

  • 分支名字尽量用新增的功能或者修复了什么 bug 命名
  • 干一点就提交一点，不然要过度rebase