乐趣区

关于git:git-基础以及多人协作

jiezi

说在后面：设置一些罕用的别名

  1. 查看咱们设置的一些命令

    cat .bashrc

  2. 编辑

    vi .bashrc

  3. 配置一些别名

    alias ga="git add"

  4. 从新 reload 一下会失效

    source .bash_profile

  5. 查看配置了哪些别名

    alias

git 与 github 什么关系？

git

open source version control software

github

  • reposity hosting
  • issue
  • pull request
  • forks

配置信息

查看本人以后全局的配置

cd ~
la
cat .gitconfig

或者

git config --list

罕用设置 name 和 email

git config --global user.name "silence717"
git config --global user.email silence717@126.com

查看以后设置是否失效

git config user.name
git config user.email

git 根底

当前目录应用 git 来进行治理，在以后文件夹下执行

git init

查看

cd .git
la

重命名文件 mv

git mv <from_file> <to_file>

与以下 3 条命令成果一样：

mv README.md README
git rm README.md
git add README

查看记录日志 log

// 查看所有记录信息
git log

// 增加数字查看最近 n 条
git log -2

// 增加 --stat 查看被批改过的文件状况
git log --stat -2

// 查看某个人的提交
git log --author=**

// 其余可配置，然而不罕用的
git log  --[since, after, until, before, ...]=**

撤销操作

// 文件 add 当前，执行 reset 能够勾销暂存, 只会影响暂存区
git reset HEAD <filename>

// commit 之后发现 msg 谬误或者遗记提交有些文件，应用合并提交
git commit --amend

// 危险命令：批改了文件，确定不想要了，应用 checkout 复原为上一次提交的文件状态
git checkout -- <file>

近程仓库的应用

// 查看近程仓库简写
git remote
// clone 一个仓库，会主动增加 origin 为 remote-name 的简写

// 参数 -v 显示近程仓库的 url
git remote -v 

// 增加
git remote add <remote-name> <url>

// 同步近程仓库
git fetch <remote-name>

// 从近程分支更新代码
git pull [remote-name] [branch-name]

// 为近程分支推送代码
git push [remote-name] [branch-name]

这块的 origin 与master分支一样，都是 git 默认生成的，与其余分支或者名称一样，没有什么非凡意义。

标签治理 tag

// 显示所有的 tag
git tag

// 新建一个 tag
git tag -a <tag-name> -m "tag info"

// 显示某个 tag 信息
git show <tag-name>

// 将以后 tag 推送到近程
git push origin <tag-name>

// 删除本地的 tag
git tag -d <tag-name>

// 危险：删除近程 tag
git push origin :refs/tags/<tag-name>

分支治理 branch

// 查看本地所有 branch
git branch

// 查看所有分支和它的最初一次提交
git branch -v

// 新建分支
git branch <branch-name>
// 切换到新建的分支
git checkout <branch-name>
git switch <branch-name>

// 新建分支、并且切换到以后分支
git checkout -b <branch-name>

// 推送到近程
git push origin <branch-name>

// 强制删除本地分支
git branch -D <branch-name>

// 删除近程分支
git push origin --delete <branch-name>

// 查看更多的分支信息
git branch -vv
// behind 2 落后于近程分支 2 条 commit
// ahead 3 本地有 2 条 commit 没有 push 到近程上
// test 未跟踪任何近程分支
// feature/form 代表和近程一样

暂存文件 stash

长期存储一些代码，正在开发的性能做了一半，须要切换分支，有的代码还在报错，没有通过 eslint 校验，因而 commit 是不能解决这个问题的，当然在这种状况下commit 代码是十分不合理的做法，因而能够应用git stash。

// 查看状态
git status

// 应用 stash 命令
git stash 
git stash save

// 查看存储的代码
git stash list

// 从新利用 stash 的某一个，如果不增加 stash-name，默认是最近的一条
git stash apply <stash-name>
// 利用完当前从栈上删除
git stash drop <stash-name>

// 间接利用并且删除它
git stash pop

merge 与 rebase

merge

将两个分支最新的提交与二者最近的独特的先人进行三方合并，合并的后果生成一个新的记录并且提交。

rebase

找到这两个分支最近的独特先人，而后比照以后分支绝对于先人的历次提交，提取相应的批改存为临时文件，将以后分支的指标基底指向最新的提交，而后将存储的临时文件的批改顺次利用，这块产生的是新的commit，而不是原来的。

如果其余小伙伴须要更新代码，肯定要应用 git pull –rebase 而不是 git pull。

雷同

成果都是统一的，将代码更新到最新，合并所有的提交。

不同

rebase是将一系列提交依照原有秩序顺次利用到另一分支上，而合并是把最终后果合在一起。

为什么 应用rebase？

之前发现有的同学并不会应用或者不晓得有 stash 这个命令的存在，因而一直在本人的分支下面 commit 代码，这样造成最初的最初一个小小的性能产生十分多的 commit 记录，也有可能 commit 到最初都不晓得填写什么 message 信息，因而呈现十分多的又没有什么意义的 commit 记录，不便于前期问题的追踪与记录。

在外部我的项目中这么做其实也没什么关系，如果去开源社区提交一个 pr，作者如果看到你这样的commit 信息会感觉你十分不业余，可能都不会去看你的代码。

我偏爱 rebase 的起因

提交历史更加整洁，有时候 merge 产生的 commit 记录对于我来说是毫无意义的。尽管实际上咱们的开发是异步的，然而历史提交记 录看起来是一条直线，没有分叉，看起来像同步的成果一样。强迫症患者举荐应用此种形式 ????????????

罕用的 git 命令

// clone
git clone 

// 更新代码
git pull origin 

// status
git status
git status -s

// 增加文件到 staging area
git add 

// 增加 msg 信息
git commit -m "commit message"

// 更新 repo
git push origin 

// 同步近程仓库信息
git fetch --all

git pull 与 git fetch 区别

git fetch 只是从近程拉取本地没有的代码，不会批改工作目录中的内容。

git pull会拉取最新的数据，并且合并到以后分支。相当于 git fetch 命令执行完紧接着执行了一条 git merge 命令。

举荐可视化工具:GitKraken

个人观点：作为程序员应用可视化工具并不可耻！

多人合作 git 版本开发

分支治理的意义？

  • 一个人并行多个工作，相互之间不影响
  • 多集体合作开发一个工作，一直提交，另外的人须要不停合并代码
  • 胆怯失落代码，须要每天 commit

达成分支命名的共识

master：当初改为main，作为主分支，代码永远与线上生产环境公布的保持一致

pre-release：预公布分支，作为上线前的回归测试应用的分支。

dev：测试分支，所有提交测试的性能代码全副合并到 dev 进行测试。

feature/**：开发性能的分支

bugfix/**：修复 issue 的分支

开发流程

1、新建分支，依照约定去命名，须要留神的是这个分支是基于 master 新建。

2、开发本人负责的性能（能够做一些模版之类的货色，应用脚本生成一些根底代码）

3、提交代码。

4、须要测试的时候合并代码到 dev 分支，提供给测试。

commit 注意事项

  • one feature, one issue, one commit
  • message 信息须要足够清晰精确，便于问题追踪，能够附带一些 issue 号啥的

  • 开发一半须要切换分支怎么办？

    • 应用 git stash 将以后代码暂存起来，清理洁净工作区，切换分支做其余开发，实现后切换回来应用 git stash pop 即可持续做开发。
    • 间接 commit，提交信息轻易写，然而请不要 push，不容许在一个性能外面始终 commit，每次改一丢丢，而后轻易编写一个 message 就提交，对于代码 review 和查追溯提交的时候没有意义。
    • 正当正确的应用 amend commit，将本次提交合并到最初一次的提交外面去。

公布版本

1、先做 code review（如果有的话，没有间接疏忽）

2、合并以后分支代码到 dev 分支，不删除本人的以后分支

3、公布 dev 分支到 qa 环境进行测试

4、测试有问题，持续在原分支进行修复，反复 1，2，3 的步骤

5、没有问题，须要公布，提交 pull request 到pre-release分支进行回归测试。小问题：为什么不间接合并到master？

6、回归验证胜利，从 pre-release 分支 pr 到master分支（应用 pr 的形式还是为了再做最初一次的 check，有人去看一下代码，没有问题进行合并，审慎）。

7、代码合并到 master 之后，须要对于以后的代码进行打 tag 解决，还是追踪问题，或者应酬一些非凡的需要开发。

其中 5 和 6 步骤中倡议应用 rebase 的形式进行代码合并，这样会使得整个代码的主线是一条线，强迫症患者举荐。还有 pre-release 分支酌情思考是否须要存在。

退出移动版