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

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

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分支酌情思考是否须要存在。