git基本操作学习

下载安装git 用户名邮箱这些基础操作百度

 

1.创建仓库

创建一个新的文件夹后 然后右键 git bash here

输入命令

git init

 

2.git add命令

git add filename(要带文件格式)

将一个新建文件或者修改了文件添加到暂存区

 

3.git commit

提交

将所有在暂存区中的文件都一次性提交当前分支上(只有git add在暂存区的才会)

一般使用 git commit -m xxxx（xxx是为提交的信息备注）

 

4.git status

查看状态 能看到哪些文件是新的 哪些进行了修改

根据下图可以发现readme.txt进行了修改

 

5.git diff filename

能看到修改的内容 （还没有add到暂存区的）diff就是difference

由下图可以看到 红色就是原来的 绿色的就是新修改的内容

 

6.git log

查看每次提交的记录

最上面的是最新的提交 显示时间和提交时的信息

可以加上参数 --pretty=oneline，只会显示版本号和提交时的备注信息

commit 后面的一大串字符是commit id 用来表示版本号

HEAD 表示当前版本

 

git log --pretty=format:"%h %s" --graph

可以简单查看分支和提交的情况

 

7.git reset

git reset --hard HEAD^  #回到上一个版本

git reset --hard commit_id   #回到指定的版本号

 

HEAD^表示上一个版本 HEAD^^表示上两个版本 要多少个版本前就多少个^

然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

 

回退版本后查看

 

这时候再git log查看 就是可以看到原来的一个版本没了 回退到上一个版本了

 

除了回到以前的版本 还可以吃后悔药 恢复回来

git reflog   #查看所有分支的所有操作记录
​
git reset --hard id  #就能吃后悔药了

 

 

8.工作区和暂存区

工作区

就是我们一开始创建的文件夹就是工作区

 

 

版本库（Repository）

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

master 和head先不说

 

当使用git add把文件添加的时 其实就是添加到暂存区

第二步使用git commit 就是一次性把暂存区的所有内容提交到当前分支

 

9.撤销修改

当修改了文件内容时

可以看到可以使用add 添加到暂存区 或者使用restore回退到当前版本的内容

如果是将文件add后又修改了 则是回到暂存区的状态

 

 

 

将文件从暂存区移除

git restore --staged  #把文件从暂存区去掉
​
git restore file  #把修改回到当前版本

 

场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git restore file

场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git restore --staged file，就回到了场景1，第二步按场景1操作。

场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。

 

10.删除文件

 

先添加一个文件 然后add到版本库

然后删除工作区的test.txt文件

查看状态可以发现 一个暂存区的内容可以提交

工作区与版本库（包括暂存区和当前分支的内容）不一样 test.txt被删除

可以通过git rm file来删除暂存区或者当前分支的 也可以通过git restore file来恢复工作区的文件

如果是git rm删除了当前分支的 需要重新commit

 

11.关联Github

在github上创建一个仓库

然后在本地工作区中 git bash

后面是根据仓库的名字

git remote add origin https://github.com/Zyfgoup/learngit

然后 就可以将本地 master分支push到仓库上了

这里的master其实是将本地哪个分支push到仓库上

git push -u master origin #加了参数-u后，以后即可直接用git push 代替git push origin master

 

这里的origin都表示远程仓库 方便辨认

 

12.远程仓库克隆

git clone [email protected]:Zyfgoup/learngit.git

 

13.分支创建和合并

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上：

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

真是太神奇了，你看得出来有些提交是通过分支完成的吗？

 

git branch dev  #创建一个分支

git checkout dev  #切换到dev分支  git switch dev  也可以 

# 合并使用  创建并切换git checkout -b dev    $ git switch -c dev

git branch  #显示所有的分支  *表示当前分支

 

可以在当前分支下创建一个文件test.txt

touch test.txt

vim test.txt

i 进入插入模式 R进入替换模式 输入完内容后 esc回到命令模式 然后输入:wq保存退出

然后add commit

再切换回master git checkout master

然后ls 可以看到仅仅只有readme.txt

 

合并

当我们切换到master后 可以将分支合并到master分支上，然后此时 master和新分支dev都指向最新的节点

然后head指向当前分支

git merge dev #将某个分支合并到merge  具体的思想上面图所示
git branch -d dev  #将分支删除

 

 

14.解决冲突

当创建一个新分支 在readme上修改了 然后commit后

切换 到master 也修改了readme 然后也commit了

此时如果merge分支 那么两个分支都对同一个文件进行修改，会显示冲突

通过git status 可以看到是哪个文件发生冲突

然后cat查看该文件 可以看到分支修改的内容是是什么

 

然后编辑文件，将文件修改为自己想要的

然后add commit

然后删除掉分支 git branch -d test即可

 

15.分支管理策略

合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

 

合并的命令

git merge --no-f -m "message" 分支名

 

git log --graph --pretty=oneline --abbrev-commit

*   e1e9c68 (HEAD -> master) merge with no-ff
|\  
| * f52c633 (dev) add merge
|/  
*   cf810e4 conflict fixed
...

 

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

 

每个新功能也应该是一个新分支 开发完毕 然后再合并 删除分支 而不是要在分支上写实验性的代码等

当一个分支还没有合并就删除的话 会提示错误

然后使用

git branch -D name  #强行删除

 

16.bug分支

当我们自己当前的业务没写完时 又来了一个新的紧急bug需要先完成 但是自己的又没写完 没发提交

工作台有修改等 不能切换分支

所以可以使用

git stash  #将目前的工作台储藏  

然后就可以切换到需要修改bug的分支 然后新建分支 来修改 修改完合并 再把分支删了

然后切换回到之前业务的写的时候的分支

但是通过 git status并没有什么信息

通过 git stash list 可以看到一些信息

然后通过 git stash pop来恢复之前工作区的内容（pop是恢复并且把stash删除）

或

git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除

当 stash很多时 可以通过 git stash apply stashid来指定恢复到哪个

 

17.多人协作

• 查看远程库信息，使用git remote -v；

• 本地新建的分支如果不推送到远程，对其他人就是不可见的；

• 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；

• 在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；

• 建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；

• 从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

18.标签

发布一个版本时，我们通常先在版本库中打一个标签（tag），这样，就唯一确定了打标签时刻的版本。将来无论什么时候，取某个标签的版本，就是把那个打标签的时刻的历史版本取出来。所以，标签也是版本库的一个快照。

Git有commit，为什么还要引入tag？

“请把上周一的那个版本打包发布，commit号是6a5819e...”

“一串乱七八糟的数字不好找！”

如果换一个办法：

“请把上周一的那个版本打包发布，版本号是v1.2”

“好的，按照tag v1.2查找commit就行！”

所以，tag就是一个让人容易记住的有意义的名字，它跟某个commit绑在一起。

 

相关命令

#先切换到要打标签的分支
git tag  #然后就给当前节点打了一个tag
git tag   #查看所有tag
git tag -d name  #删除tag

 

 

默认标签都是打在commit上的 ，如果忘记打标签了怎么办

方法是找到历史的commit id

git log --pretty=oneline --abbrev-commit #查看commit id


git tag v0.9 f52c633 #指定commit id上打上tag

 

19 git rebase

在工作中 如果需求或者bug改完了 commit到本地仓库了

然后要先拉取远程仓库 来合并看是否有冲突

可以通过git fetch 然后git merge来合并看是否有冲突

也可以通过git pull来代替这两个命令

而用这种形式的话 会保留各种分支的情况

 

而使用rebase会把分支的节点像删除了一样，把最新的节点连接到要连接master上，这样就是一条直线的master分支 更方便

 

而在开发过程中一般都是使用

git pull -rebase origin master 拉取远程主分支的情况 并进行合并

如果没有冲突则直接push当前本地分支

 

如果冲突则解决冲突后 使用 git add

然后使用 git rebase --continue来继续rebase操作（变成一个新节点 并且与master合并）

然后再把当前分支push到远程仓库即可

 

后面再合并远程仓库的分支就搞定了！