git现
git config -global user.name"用户名"
git config -global user.email"邮箱”
//初始化仓库
git init
//将文件添加到仓库（提交修改和提交新文件都是这个指令）
git add 文件名字
//把文件提交到仓库
git commit -m “提交的说明”
//仓库当前的状态（可以查看是否被修改）
git status
//查看修改的地方
git diff 文件名
// 显示从最近到最远的提交日志
git log 或者 git log --pretty=oneline
//回退到上一个版本
git reset --hard HEAD^
//回退到上上一个版本
git reset --hard HEAD^^
//回退到指定版本（回退100个版本）
git reset --hard HEAD~100
// 返回指定版本（commit id：1094a....）
git reset --hard commit id
//记录每一次命令
git reflog
穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本
工作区和暂存区
工作区：当前目录
暂存区：目录里面的.git文件是Git的版本库，存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。
我们把文件往Git版本库里添加的时候，是分两步执行的：
第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；
第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。
简单的来说可以理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。
//丢弃工作区的修改
git checkout -- 文件名
**把文件在工作区的修改全部撤销，这里有两种情况
**
一种是文件自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
一种是文件已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
总之，就是让这个文件回到最近一次git commit或git add时的状态。
//暂存区的修改撤销掉,重新放回工作区
git reset HEAD 文件名
小结
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD ，就回到了场景1，第二步按场景1操作。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。
//删除文件
rm 文件名
//版本库中删除该文件
git rm 文件名
git commit -m "说明文字"
添加远程库
git remote add origin [email protected]:路径
git push -u origin master //（第一次推送master分支时，加上了-u参数，把本地的master分支和远程的master分支关联起来）
//简化命令
git push origin master
//查看远程库信息
git remote -v
//删除远程库（解除和远程库的绑定）
git remote rm origin
从远程库克隆
方式是先创建远程库，然后，从远程库克隆
git clone [email protected]:git库地址
创建与合并分支
//创建分支
git checkout -b dev// git branch dev和git checkout dev两步
// 或者
git switch -c dev
// 切换分支
git checkout 分支
//或者
git switch 分支
//查看当前分支
git branch
//其他分支合并到当前分支上(例:将dev分支合并到当前的master分支上)
git merge dev
//删除分支（例：删除dev分支）
git branch -d dev
--------------------------------------------------------------------Bug分支------------------------------------------------------------------------------------
bug情景：
当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，
但是，当前正在dev上进行的工作还没有提交。并不是你不想提交，而是工作只进行到一半，
还没法提交。但是，必须在两个小时内修复该bug，怎么办？
步骤如下：
1.//当前工作现场“储藏”起来
git stash
2.//确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支
git checkout master
git checkout -b issue-101
3.修复bug，然后提交
4.修复完成后，切换到master分支，并完成合并，最后删除issue-101分支
git switch master
git merge --no-ff -m "merged bug fix 101" issue-101
5.接着回到dev分支干活
git switch dev
git status
git stash list
6.Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了
git stash apply
git stash drop
//或者
git stash pop
6.1同样的bug，要在dev上修复，我们只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。
注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。
git branch //当前应该在dev分支上
git cherry-pick 4c805e2 //4c805e2 是指你提交时候的那个commit id
// 拉取代码
git pull
//查看远程库信息
git remote -v
多人开发修改了一个文件解决方法
情景：
clone默认情况下只能看到本地master分支，要在dev分支上开发，必须创建远程origin的dev分支到本地，
git checkout -b dev origin/dev
就可以在dev上修改了
如果多人修改了同一个文件,推送会出现冲突，解决如下(出现原因是没有指定本地dev分支与远程origin/dev分支的链接)：
git branch --set-upstream-to=origin/dev dev
git pull
但是合并的时候有冲突，需要手动解决冲突即可。
因此，多人协作的工作模式通常是这样：
1.首先，可以试图用git push origin
2.如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并
3.如果合并有冲突，则解决冲突，并在本地提交
4.没有冲突或者解决掉冲突后，再用git push origin
如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to
这就是多人协作的工作模式，一旦熟悉了，就非常简单。
标签
//切换到需要打标签的分支上
git branch
//创建标签
git tag v1.0
//查看所有标签
git tag
默认标签是打在最新提交的commit上的
如果给之前提交的打标签的话，找到历史提交的commit id打上就可以了
git log --pretty=oneline --abbrev-commit //所有提交的版本展示
// 给之前的某一个打标签
git tag 标签名 commit id
// 删除标签(本地)
git tag -d 标签名
//删除远程的标签
1.git tag -d 标签名
2.git push origin :refs/tags/标签名
//推送标签到远程
git push origin 标签名
//推送所有没有推送到远端的标签
git push origin --tags
//将master分支上代码同步更新到dev分支上
//1.首先切换到master分支上
git checkout master
//2.拉取代码
git pull
//3.切换到dev分支上
git checkout dev
//4.把master分支的代码merge到自己的分支
git merge master
//5.git push推上去ok可以了。
git push origin dev