├── gitCommand ├── git 命令.png └── git.md └── .gitignore /gitCommand/git 命令.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/a18634759730/gitOperating-/HEAD/gitCommand/git 命令.png -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Logs 2 | logs 3 | *.log 4 | npm-debug.log* 5 | yarn-debug.log* 6 | yarn-error.log* 7 | 8 | # Runtime data 9 | pids 10 | *.pid 11 | *.seed 12 | *.pid.lock 13 | 14 | # Directory for instrumented libs generated by jscoverage/JSCover 15 | lib-cov 16 | 17 | # Coverage directory used by tools like istanbul 18 | coverage 19 | 20 | # nyc test coverage 21 | .nyc_output 22 | 23 | # Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files) 24 | .grunt 25 | 26 | # Bower dependency directory (https://bower.io/) 27 | bower_components 28 | 29 | # node-waf configuration 30 | .lock-wscript 31 | 32 | # Compiled binary addons (https://nodejs.org/api/addons.html) 33 | build/Release 34 | 35 | # Dependency directories 36 | node_modules/ 37 | jspm_packages/ 38 | 39 | # TypeScript v1 declaration files 40 | typings/ 41 | 42 | # Optional npm cache directory 43 | .npm 44 | 45 | # Optional eslint cache 46 | .eslintcache 47 | 48 | # Optional REPL history 49 | .node_repl_history 50 | 51 | # Output of 'npm pack' 52 | *.tgz 53 | 54 | # Yarn Integrity file 55 | .yarn-integrity 56 | 57 | # dotenv environment variables file 58 | .env 59 | 60 | # next.js build output 61 | .next 62 | -------------------------------------------------------------------------------- /gitCommand/git.md: -------------------------------------------------------------------------------- 1 | # GIT 2 | 重新创建 3 | ### 首先要明白四个空间：远程仓库，本地仓库，本地缓存区，本地工作区； 4 | ####远程仓库： 5 | 该仓库是一个集中的数据仓库，正常情况下，所有参与开发的人员的代码最后都会提交到该仓库的自己的分支上，再由具有合并权限的人员来合并所有分支； 6 | 7 | ####本地仓库： 8 | 一般来说，本地仓库是由开发人员通过clone复制远程仓库中的某个分支的数据到本地而产生的，但git不是集中式的版本控制，而是分布式的版本控制，他们的区别就是，分布式版本控制中每一个仓库都能具有远程仓库的作用，而集中式的版本控制中远程仓库是不能被其他参与开发的人备份的； 9 | 10 | ####本地缓存： 11 | 在本地修改数据后（一般是指我们在编辑器中修改某个文件），git监测到该数据与本地数据仓库的数据不一致，会提示将该修改增加（add）到缓存区，缓存区中的文件可以用来与本地仓库中的文件进行比较（difftool），这个用处目前感觉主要用于当我们修改很多文件时，最后不记得自己修改了那些文件，如果没有缓存区，我们直接提交的话，很容易会导致很多疏忽。我们在编辑器中修改了文件后（本地工作区），本地缓存中不包含我们的修改的，只有当我们把本次的修改add到缓存区的时候，缓存区中才有本次的修改，这表明我们的每一次修改都必须手动add到本地缓存中才能在使用commit命令时将其添加到本地仓库。 12 | 13 | ####本地工作区： 14 | 也就是我们的编辑器的空间； 15 | 16 | ##分支命名规则 17 | 1.主分支：master 18 | 2.CICD： autoDeploy 19 | 3.开发分支：develop 20 | 4.功能分支：feature-分支名称/功能名称 (例： git checkout -b feature-autoMLlist) 21 | 5.分支发布：release-日期 22 | 6.bug 分支修复：bugfix-日期 23 | ##分支开发节点 24 | 鉴于此后在代码管理流程上，需按严格要求执行，所以在每日开发的功能或者bug必须于当日完成以及提交pull request,便于代码review。 25 | ##开发流程 26 | > 在develop分支，多人需要开发不同的功能，这里就会用到feature分支。团队中的每个人都从Github克隆一个项目，然后新建自己的feature分支。 27 | 28 | * git clone xxxx.git 29 | * git checkout develop 30 | * git checkout -b feature-×× develop # 从develop分支新建并检出feature分支） 31 | > 这里可以进行一些功能开发，并不断的add和commit 32 | * git checkout develop # 切换回develop分支 33 | * git pull origin develop # 更新远端代码，看develop分支是否有更新（无更新） 34 | * git checkout feature-×× # 切换回feature分支 35 | * git rebase develop # 合并develop分支到feature分支，并解决冲突（无冲突） 36 | * git checkout develop # 切换回develop分支 37 | * git merge --no-ff feature-hu # 合并feature分支到develop分支 38 | * git push origin develop # 推送develop分支到远端 39 | 40 | ###下面遇到冲突解决 41 | #####对于团队其他成员开发，操作如下，并打算在上面提交后进行push操作 42 | * git checkout -b feature-zz develop # 从develop分支新建并检出feature分支 43 | > 这里可以进行一些功能开发，并不断的add和commit 44 | * git checkout develop # 切换回develop分支 45 | * git pull origin develop # 更新远端代码，看develop分支是否有更新（有更新） 46 | * git checkout feature-×× # 切换回feature分支 47 | * git rebase develop # 合并develop分支到feature分支，并解决冲突（有冲突） 48 | > 这里需要进行冲突解决 49 | * git add . # 解决完冲突之后执行add操作 50 | * git rebase --continue # 继续刚才的rebase操作 51 | * git checkout develop # 切换回develop分支 52 | * git merge --no-ff feature-×× # 合并feature分支到develop分支（无冲突） 53 | * git push origin develop # 推送develop分支到远端 54 | 55 | 56 | ![image](https://github.com/RenGitName/GIT/blob/develop/--no-ff.png) 57 | 58 | 59 | 60 | ###git merge 与 git rebase 区别 61 | 62 | *对于使用git merge来合并所看到的commit的顺序（从新到旧）--> 根据提交的时间顺序排列下来 63 | *对于使用git rebase来合并所看到的commit的顺序（从新到旧） --> 合并之后主分支会重新克隆被合并的分支提交信息并到主分支上 64 | 65 | 66 | ###git stash 暂存代码 67 | 68 | *通过git stash save 'message'这条命令把未保存的修改的代码提交到本地暂开的仓库 69 | *通过git stash pop stash@{0} 可以恢复之前被暂存的代码 70 | *git stash list 可以查看现有的所有stash信息 71 | *git stash drop 可以删除某个或全部stash信息 单个为直接后面跟信息名称 72 | 73 | *此执行命令可以使得在开发人员未开发完成此次功能时，需介入其他分支开发， 所有可以使用这些命令管理这些未完成代码 74 | 75 | 76 | 77 | ###回退版本 78 | 79 | *git reset --hard HEAD^ 可以回退到上一个版本，也可以直接跟每一个的版本信息 直接跳到该版本信息下（查看版本信息是git log） 80 | *如果在回退回去之后后悔，也可以再返回，但需要知道版本号（版本ID），通过 git reflog查到每一个版本信息ID， 输入然后跳转 81 | 82 | *git diff 可以列举出本次提交修改过的代码 83 | 84 | 85 | --------------------------------------------------------------------------------