git秘钥使用：
- 在.ssh 目录下右键打开Git Bash(.ssh目录不存在，手动创建)
- 生成秘钥：ssh-keygen -t rsa -C "[email protected]" ，直接Enter就行，然后会提示输入密码(可输可不输) 说明：命令中的email，就是gitlab中的账号，需要保持一致
- 执行完成之后，在.ssh 目录下就会生成秘钥文件
常用指令：
# 从远程clone代码： git clone ‘项目远程地址’ eg：git clone ssh://******.git # 查看远程所有分支： git branch -a # 查看上次提交修改的文件内容 git diff # git clone 时，报错用户名密码错误，解决： git config --system --unset credential.helper 清除本地用户名密码，重新输入即可clone # git暂存 git stash save "暂存的备注" git stash list git stash pop git reset --hard # 搜索分支名称 git branch --all | grep <id> # 创建并切换分支：git checkout -b 20181218wangzs # 创建并切换远程分支 git checkout -b dev origin/dev # 创建分支：git branch <分支名称> # 切换分支：git checkout '分支' # 提交本地分支到远程仓库：git push origin 本地分支名 eg: github上已经有master分支 和dev分支 在本地 git checkout -b dev 新建并切换到本地dev分支 git pull origin dev 本地分支与远程分支相关联 在本地新建分支并推送到远程 git checkout -b test git push origin test 这样远程仓库中也就创建了一个test分支 # 查看commit内容 git show commit_id # git 远程添加地址： git remote add origin '地址' 向远程推送仓库时，加上-u 参数，不仅将本地推送到远程，并且和远程master版本号关联起来。 git push -u origin master. # 合并分支： 在当前分支执行指令： git merge <分支名称> # 查看分支： git branch # 删除分支： git branch -d <分支名称> # git 版本升级后问题 git版本升级后，报错：ssh variant 'simple' does not support setting port 使用命令：git config --global ssh.variant ssh # git 版本升级后问题 git版本升级后，报错：ssh variant 'simple' does not support setting port 使用命令：git config --global ssh.variant ssh # fork库更新源码 1. 查看下当前远程仓库 git remote -v 2. git 添加远程仓库 git remote add new-url '远程仓库地址'。大家公共使用的远程地址 3. 从上游仓库fetch 分支 git fetch new-url 4. 合并更新仓库的master到本地分支上 git merge new-url/master 5. 将更新后的本地 add commit push 上传到fork，实现对fork库的更新 git add . git commit -m '更新fork库' git push # git解决冲突(一) <<<<<<< HEAD head指向的分支修改内容 ======= 分割前后冲突 >>>>>>> feature1 被合并分支上的修改内容 # git 解决冲突(二) 在提交代码和merge代码的时候，都可能会产生代码冲突的情况。 用idea解决冲突的时候，分为3部分: [本地代码] [解决完冲突后的结果代码] [远程代码] 解决冲突的时候，冲突包括两部分：changed和conflict conflict: 就是本地代码和远程代码想冲撞的地方。如果既想保留本地代码也想保留远程代码，可同时引用本地和远程代码(看实际情况) changed: 就是本地代码和远程代码相对来说没有冲撞，但是有不一样的地方。 如果只有本地和result有changed，可以选择忽略本地修改，result即跟远程代码一致。如果只有远程和result有changed，可以选择忽略远程代码的不一致，即result跟本地代码保持一致，也可以选择使用远程代码，result代码即跟远程代码保持一致，如果本地代码和远程都有changed，可以选择忽略本地代码，result即和远程代码保持一致。我解决冲突的原则，尽量和远程代码保持一致，保证merge request的时候没有冲突。 # git解决冲突(三)： 1. 更新代码冲突： 更新代码的冲突是远程分支和本地分支代码的冲突。 清楚自己改的代码 和别人提交到远程修改的代码，要使用哪个修改，引用哪个就可以。 所以在每天自己开发前 都要pull代码；在push代码前一定要pull，否则就会造成代码冲突 2. merge代码冲突 merge代码冲突是自己本地分支代码和远程另一个分支的冲突。 清楚自己改的代码 和别人合并到远程分支修改的代码 3. cherry-pick代码冲突 是某次提交合并到远程分支。某次提交时的代码和远程分支现在的代码发生冲突。 4. 退出cherry-pick: git cherry-pick --abort # git 撤销| soft | mixed | hard | |
| commit | 撤销 | 撤销 | 撤销 |
| add . | 不撤销 | 撤销 | 撤销 |
| 工作空间代码改动 | 不撤销 | 不撤销 | 撤销 |
## git分支的命名规范： git 分支分为集成分支、功能分支和修复分支，分别命名为 develop、feature 和 hotfix，均为单数。不可使用 features、future、hotfixes、hotfixs 等错误名称。 ● master（主分支，永远是可用的稳定版本，不能直接在该分支上开发） ● develop（开发主分支，所有新功能以这个分支来创建自己的开发分支，该分支只做只合并操作，不能直接在该分支上开发） ● feature-xxx（功能开发分支，在develop上创建分支，以自己开发功能模块命名，功能测试正常后合并到develop分支） ● feature-xxx-fix(功能bug修复分支，feature分支合并之后发现bug，在develop上创建分支修复，之后合并回develop分支。PS:feature分支在申请合并之后，未合并之前还是可以提交代码的，所以feature在合并之前还可以在原分支上继续修复bug) ● hotfix-xxx（紧急bug修改分支，在master分支上创建，修复完成后合并到 master） 注意事项： ● 一个分支尽量开发一个功能模块，不要多个功能模块在一个分支上开发。 ● feature 分支在申请合并之前，最好是先 pull 一下 develop 主分支下来，看一下有没有冲突，如果有就先解决冲突后再申请合并。 ## git查看自己提交代码总行数： git log --pretty=tformat: --numstat | awk '{ add += $1; subs += $2; loc += $1 - $2 } END { printf "added lines: %s, removed lines: %s, total lines: %s\n", add, subs, loc }' - ## git查看 指定人员-指定时间段内 提交的代码总行数： git log --author="wangzhaoshuang01" --since='2020-12-20' --until='2020-12-26' --pretty=tformat: --numstat | gawk '{ add += $1 ; subs += $2 ; loc += $1 - $2 } END { printf "增加的行数:%s 删除的行数:%s 总行数: %s\n",add,subs,loc }' eg: git log --since='2020-05-24' --until='2020-05-30' --format='%aN' | sort -u | while read name; do echo -en "wang**"; git log --since='2020-05-24' --until='2020-05-30' --author="wang**" --numstat --pretty=tformat: --no-merges | awk '{ add += $1; subs += $2; loc += $1 - $2 } END { printf "added lines, %s, removed lines, %s, total lines, %s\n", add, subs, loc }' -; done >> 2020_0601_code.csv; ## jar各个版本号的意义 jar版本号的意义： Alpha： Alpha是内部测试版,一般不向外部发布,会有很多Bug.除非你也是测试人员,否则不建议使用.是希腊字母的第一位,表示最初级的版本，alpha 就是α，beta 就是β ，alpha 版就是比 beta 还早的测试版，一般都是内部测试的版本。 Beta: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一缺陷，需要经过多次测试来进一步消除。这个阶段的版本会一直加入新的功能。 RC：(Release Candidate) Candidate是候选人的意思，用在软件上就是候选版本。Release.Candidate.就是发行候选版本。和Beta版最大的差别在于Beta阶段会一直加入新的功能，但是到了RC版本，几乎就不会加入新的功能了，而主要着重于除错!RC版本是最终发放给用户的最接近正式版的版本，发行后改正bug就是正式版了，就是正式版之前的最后一个测试版。 GA：（general availability） 比如：Apache Struts 2 GA这是Apache Struts 2首次发行稳定的版本，GA意味着General Availability，也就是官方开始推荐广泛使用了。 Release: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。 标签：常用,git,--,代码,功能,本地,远程,分支 From： https://www.cnblogs.com/wangzhaoshuang/p/16902461.html