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

  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 ~lacat .gitconfig

或者

git config --list

罕用设置name和email

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

查看以后设置是否失效

git config user.namegit config user.email

git根底

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

git init

查看

cd .gitla

重命名文件 mv

git mv <from_file> <to_file>

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

mv README.md READMEgit rm README.mdgit 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 显示近程仓库的 urlgit 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

// 显示所有的taggit tag// 新建一个taggit tag -a <tag-name> -m "tag info"// 显示某个tag信息git show <tag-name>// 将以后tag推送到近程git push origin <tag-name>// 删除本地的taggit tag -d <tag-name>// 危险：删除近程taggit push origin :refs/tags/<tag-name>

分支治理 branch

// 查看本地所有branchgit 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 命令

// clonegit clone // 更新代码git pull origin // statusgit statusgit status -s// 增加文件到 staging areagit add // 增加msg信息git commit -m "commit message"// 更新repogit 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分支酌情思考是否须要存在。