配置git账户信息
在第一次配置 Git 时，您需要设置 Git 的全局用户名和邮箱地址。
git config --global user.name "yourname"
git config --global user.email "youremail"
这些信息将与您在 Git 上执行的每个提交一起记录。在配置完成后，Git 将使用您的 Git 提供商（如 GitHub、GitLab 等）保存的凭据来识别您的身份，并允许您进行操作。因此，您需要在第一次使用 Git 提交代码时输入您的账号和密码。如果您想避免每次操作时输入凭据，可以考虑使用 SSH 密钥进行身份验证。
vscode设置了公钥为什么每次推送还要我输入账号密码?
可能需要设置git的凭证存储器，让git记住您的用户名和密码，这样就不用每次推送都输入了。您可以在VS Code的终端中输入以下命令：
git config --global credential.helper store
本地仓库与远程仓库关联
生成SSH
ssh-keygen -t rsa -C "your_email@example.com"
SSH-Key一键复制
#mac
pbcopy < ~/.ssh/id_rsa.pub
#Windows
clip < ~/.ssh/id_rsa.pub
#Linux
sudo apt-get install xclip
# Downloads and installs xclip.
#If you don't have `apt-get`, you might need to use another installer (like `yum`)
xclip -sel clip < ~/.ssh/id_rsa.pub
# Copies the contents of the id_rsa.pub file to your clipboard
在C盘用户下有一个.ssh文件夹,文件夹中有一个id_rsa.pub和id_rsa两个文件,id_rsa.pub里面的信息是公钥,而id_rsa里面的是私钥.
与你的Gitee远程仓库关联
- 登录到Gitee的账户中心，点击“设置”按钮，然后选择“SSH公钥”选项。
- 点击“添加SSH公钥”按钮，并将本地生成的公钥内容复制到“公钥”输入框中。
- 为了方便识别，可以在“公钥名称”输入框中输入一个有意义的名称，以便以后识别。
- 最后，点击“确认”按钮，Gitee将会保存您的公钥，以便在使用SSH协议访问Gitee时进行身份验证。
注意：在使用SSH访问Gitee时，还需要在本地配置私钥。如果您在生成公钥时使用了不同的文件名，那么在配置私钥时需要相应地替换文件名。
与你的GITHUB远程仓库关联
- 登录到GitHub的网站中，点击右上角的头像，选择“Settings”选项。
- 在左侧导航栏中，选择“SSH and GPG keys”选项。
- 点击“New SSH key”按钮，并将本地生成的公钥内容复制到“Key”输入框中。
- 为了方便识别，可以在“Title”输入框中输入一个有意义的名称，以便以后识别。
- 最后，点击“Add SSH key”按钮，GitHub将会保存您的公钥，以便在使用SSH协议访问GitHub时进行身份验证。
建立本地仓库
初始化本地仓库
git init //初始化仓库,会在当前文件夹创建一个.git文件夹
第一次推送到远程仓库
git remote add origin 'https://gitee.com/${自己的账号}/${远程的仓库名字}.git'
git push -u origin "master"
第一次拉取代码到本地（默认分支）
git clone "https://gitee.com/${自己的账号}/${远程的仓库名字}.git"
拉取特定分支到本地
# 拉取远程 dev 分支到本地
git clone -b dev "https://gitee.com/${自己的账号}/${远程的仓库名字}.git"
修改远程仓库地址
git remote set-url origin "https://gitee.com/${自己的账号}/${远程的仓库名字}.git"
删除远程仓库
删除前可先用git remote -v查看远程库信息:
origin https://gitee.com/yangxiaoming1924/git-test.git (fetch)
origin https://gitee.com/yangxiaoming1924/git-test.git (push)
然后，根据名字删除，比如删除origin：
git remote rm origin
此处的删除其实是解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库，需要登录到GitHub/Gitee，在后台页面找到删除按钮再删除。
git推送到暂存区,本地仓库,远程仓库
添加到暂存区
git add . //这里的.代表的是所有文件
git add <file> //指定添加某个文件
这里的.代表的是所有文件 ,若要指定某个文件可以使用git add <file>
添加到本地仓库
git commit -m '注释说明' // 通过在commit信息中添加 #issue ID 可以关闭对应的issue
git commit -am '跳过add阶段直接commit'
git commit -m --allow-empty //提交空commit
添加到远程仓库
git push //默认添加到master主分支
git push origin dev //添加到指定分支,如 dev
git分支相关操作
查看当前所有分支
git branch //查看所有分支,前面带有 * ,高亮显示的代表当前所在分支
建立新分支
git checkout -b dev //这里创建了一个新的分支 dev
git switch -c hotfix //这里用新版 switch 命令 -c代表创建 hotfix 分支
git branch -c fix //这里新建了一个 fix 分支
切换分支
git checkout dev //切换至 dev 分支
git switch dev // 切换到 dev 分支
分支推送到远程仓库
git push origin 新的分支名 //将指定分支推送到远程仓库
分支合并
强调：合并之前，必须保持：当前分支的 本地仓库 与 远程仓库 一致。
git merge dev //将 dev 分支与当前分支合并
若发生冲突怎么办?
git分支冲突是指在合并或推送不同的分支时，出现了相同文件的不同修改，导致git无法自动合并。解决git分支冲突的一般步骤是：
- 执行
git status命令，查看哪些文件有冲突。 - 打开有冲突的文件，找到
<<<<<<<和>>>>>>>之间的部分，这是两个分支的不同修改。 - 根据需要，手动选择保留或删除其中一个或两个分支的修改，或者编辑一个新的修改。
- 保存文件，执行
git add命令，将解决了冲突的文件添加到暂存区。 - 执行
git commit命令，提交解决了冲突的版本。 - 如果有多个文件有冲突，重复上述步骤直到所有文件都解决了冲突。
删除分支
git branch -d dev //删除本地 dev 分支
git push origin --delete dev //删除远程 dev 分支
分支管理策略
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
git merge --no-ff -m "merge with no-ff" dev
因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
Bug分支
软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交
并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？
幸好，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
git stash
Saved working directory and index state WIP on hotfix: d7b212d dev commit
现在，用git status查看工作区，就是干净的 （除非有没有被Git管理的文件） ，因此可以放心地创建分支来修复bug。修复完毕后,回到dev分支继续工作,发现写的东西不见了,这是可以使用如下命令:
//先查看被 冻结 的代码
git stash list
//第一种方式用这个恢复，但是恢复后，stash内容并不删除你需要用git stash drop来删除；
git stash apply
//第二种是这种恢复,同时会把stash内容也删了
git stash pop
再用git stash list查看，就看不到任何stash内容了,你可以使用多次stash恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
git stash apply stash@{0}
只合并fixbug代码,不合并整分支
在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。
那怎么在dev分支上修复同样的bug？重复操作一次，提交不就行了？
有木有更简单的方法？
有！
同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。
注意:我们只想复制4c805e2 fix bug 101这个提交所做的修改,并不是把整个master分支merge过来。
为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：
git cherry-pick 4c805e2 //在当前分支 dev 下"复制" 修复bug的commit id
git查看相关状态信息
查看git日志信息
git log //包括提交者姓名,邮箱.提交日期,提交commit备注信息,以及代表当前唯一的哈希值
git log --pretty=oneline //如果嫌输出信息太多，看得眼花缭乱的，可以试试加上该参数
查看当前文件状态
git status //查看当前文件状态包括 是否在暂存区,本地仓库,以及冲突文件
git版本回滚
一切前提是没有推送到远程库
git回到过去
git reset //移除所有暂存区修改,不会修改工作区
git reset --hard //移除所有暂存区修改,会修改工作区!!!!!
git reset --hard HEAD^ //一个 ^ 代表上个版本 ^^ 代表两个版本 若回滚版本过多可用 HEAD~100
git穿越未来
这里的命令行不要关闭,一定要记住之前的commit id
18fce7579963e7fb8c710a0e4457297f616668d5 merge 冲突解决
上面的为 回退之前的版本
可用下面的命令回到最新的
git reset 18fce // 将当前分⽀回滚到指定<commit>，清除暂存区的修改，但保持⼯作区状态不变。
git reset --hard 18fce //将当前分⽀回滚到指定<commit>，清除暂存区的修改，
//并强制删除所有⼯作区的修改。
现在，你回退到了某个版本，关掉了电脑，第二天早上就后悔了，想恢复到新版本怎么办？找不到新版本的commit id怎么办？
在Git中，总是有后悔药可以吃的。当你用 git reset --hard HEAD^回退到之前版本时，再想恢复到最新，就必须找到之前的commit id。Git提供了一个命令git reflog用来记录你的每一次命令：
git reflog
e475afc HEAD@{1}: reset: moving to HEAD^
1094adb (HEAD -> master) HEAD@{2}: commit: append GPL
e475afc HEAD@{3}: commit: add distributed
eaadf4e HEAD@{4}: commit (initial): wrote a readme file
终于舒了口气，从输出可知，之前的commit id是1094adb，现在，你又可以乘坐时光机回到未来了。
撤销修改
git checkout -- <file> //回退到最近的上次commit或者add状态
git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。
如果在git commit之前发现了需要撤销的操作 用git status查看一下，修改只是添加到了暂存区，还没有提交：
git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: test.html
Git同样告诉我们，用命令git restore --staged <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区,使用git status查看:
git restore --staged test.html
git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: test.html
no changes added to commit (use "git add" and/or "git commit -a")
这里我们发现已经从staging暂存区回退到了workspace工作区,可以执行git checkout -- test.html将workspace工作区的内容撤销,大功告成!
删除文件
先将一个rm.html通过git add和git commit -m "add rm.html"添加到local respository版本库中,再执行以下操作:
rm "rm.html"
git rm "rm.html" //这两种效果与手动删除文件效果一样
另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：
git checkout -- "rm.html"
git checkout其实是用local respository版本库里的版本替换workspace工作区的版本，无论workspace工作区是修改还是删除，都可以一键还原。
注意：从来没有被添加到版本库就被删除的文件，是无法恢复的！
命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
标签管理
创建标签
git tag <name> //给当前分支打标签 例如 git tag v1.0 一个分支可打多个标签
查看标签
git tag //查看当前分支所有tag
往期打标签
git tag v0.9 f52c633 //这里给commit id 为 f52c633的记录打了一个标签为 v0.9
标签说明
git tag -a v0.1 -m "version 0.1 released" 1094adb //用"-a"指定标签名，"-m"指定说明文字
注意:标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。
删除标签
git tag -d v0.1 // 删除标签
远程推送
git push origin v1.0 //推送某个标签到远程
git push origin --tags //一次性推送全部tag
远程删除
如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：
git tag -d v1.0
然后，从远程删除。删除命令也是push，但是格式如下：
git push origin :refs/tags/v1.0
多人协作
流程如下
- 首先，可以试图用
git push origin <branch-name>推送自己的修改； - 如果推送失败，则因为远程分支比你的本地更新，需要先用
git pull试图合并； git add . / git commit -m "描述"之后,建立PR合并申请审批;- 如果合并有冲突，则解决冲突，并在本地提交；
- 没有冲突或者解决掉冲突后，再用
git push origin <branch-name>推送就能成功！
如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
自定义Git
显示颜色
git config --global color.ui true //适当显示不同颜色
忽略特殊文件
- 忽略某些文件时，需要编写.gitignore；
- .gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！
配置别名
git config --global alias.st status //将 status 配置别名 st
git config --global alias.unstage "reset HEAD" //从 staging暂存区回退到workspace工作区
