git踩坑笔记
(一) git pull冲突问题
若文章有误，欢迎读者指出了解
git pull
git pull命令用来从远程仓库下载更新内容，并立即将对应内容更新到本地仓库。在Git的协作工作流中，合并远程仓库变更到本地仓库是很常见的工作。而git pull命令实际上就是其他两个命令的结合体，先git fetch然后紧接着git merge。在git pull命令执行的第一个阶段，会先对当前本地HEAD指针指向的分支执行git fetch。当原称更新内容下载完成之后，git pull会接着进入合并流程。合并操作会创建一个新的commit，并且HEAD指针也会随之更新而指向这个新的commit。
我遇到的问题：由于远程仓库较新，而我本地仓库较旧，于是推送不上去，git希望我git pull，一执行出现了远程覆盖本地的情况，但是我本地代码是我写好要推送远程仓库的代码。
- 回到之前版本又不让我推送，而现在这个版本又不是我想要的，于是想了一个笨办法，回退到之前版本，把我写好的代码备份一下，再拉取远程这样本地仓库就能和远程仓库版本同步，再把备份好的某个文件和你拉取不符合的文件直接替换掉，再提交推送，成功！！
- 具体操作：回滚，
git log，查看一下版本号，取之前版本对于版本号的号前六位，git reset --hard 版本号前六位，把整个项目文件或者写好的代码文件进行备份，再拉取远程仓库代码git pull，文件替换，添加提交推送三部曲，然后就成功了！！ - 其实网上也又很好的解决方案，例如分支啊，以及
git rebase，由于git pull经常回帮你执行合并git merge，其实可以设置一下git config --global branch.autosetuprebase always
pull 与 rebase
扩展：
--rebase选项的加入不会产生额外的合并提交，因此会保证整个提交历史是线性的。很多开发者相对于merge更加喜欢使用rebase，因为后者更像是 “我要把我的变更放在其他人已经提交的变更之上”。这一流程在很多协作场景下显得更加自然。
事实上，由于pull --rebase的工作流程如此常见，以至于在git中有一个专用的配置项为之而生。
1 | git config --global branch.autosetuprebase always |
执行以上命令之后，所有的
git pull命令都将以git rebase的方式整合远程变更，而不是以git merge的方式。
git pull + rebase，以下示例展示如何使用rebase方式同步并更新远程仓库的main分支：
1 | git checkout main |
执行以上命令会将你在本地对main分支的提交放到所有其他人的提交之上。
(二) git push报错
报错： unable to access ‘https://github.com/coding327/xxx.git/': OpenSSL SSL_read: Connection was reset, errno 10054
解决方法：git config --global http.sslVerify "false" 再重新推送
git回滚到指定版本后，版本落后于远程仓库，如何提交到远程分支?
远程仓库上面显示提交时间是和你从暂存区提交本地仓库提交时间保持一致，而不是说你从本地仓库提交到远程仓库的时间就是远程仓库上面显示提交时间git reflog 可以查看所有分支的所有操作记录包括已经被删除的commit记录和reset的操作
git log 可以显示所有提交过的版本信息
二者的区别：用git log 则看不出来被删除的commitid,用git reflog 则可以看到被删除的commitid
git reset –hard HEAD 切换到版本号为HEAD的那个版本 （个人喜欢使用git log 可以看到commit的时间）
如果冲突的话，对于个人仓库我一般都会强制推送，可以使用 git push -f origin test 强制推送到远程分支，-f 强制，origin 远程仓库名，test 远程分支名
微信- 支付宝
