Git使用

Mr_JIE
209 阅读10分钟

创建远程仓库

1. 创建远程仓库
cd 到 文件夹
git init --bare

2. cd 到你要上传的文件根目录
git init //先初始化
git remote add origin Parth //然后添加远程仓库 可以添加多个 目的就是 把代码 推到 1创建的远程仓库

3.远程仓库添加好后 在你本地仓库 执行 commit 操作
git add .
git commit -m 'init'
或者直接执行 git commit -am 'init' 等同与上面代码的合并。
git push 
这时应该会有问题 
会提示：git push --set-upstream origin master
按照提示执行就行了，这个原因 是 分支相关问题。随后再解答。
好了 这时 远程仓库基本上就搞完了。代码也推到远程仓库了。

这时 另一个人 想要开发 怎么办呢，

git remote add -t master origin Parth

config

git有三个地方可以设置姓名和邮箱

  • /etc/gitconfig (几乎不会使用) ,通过git config --system设置
  • ~/.gitconfig (很常用) 通过git config --global设置
  • 针对于特定项目，在项目的.git/config文件中 (很常用) ，通过git config --local设置。 优先级 local > global > system

git config user.name
git config user.email
git config --list 查看当前的git配置，包括用户名，邮箱等

全局区修改
git config --global user.name "xx"
git config --global --replace-all user.name "xx"

指定仓库区修改
git config user.name "xx"

clone

从远程主机克隆一个版本库
git clone <url>

remote

  • 添加远程仓库 origin:起个别名 Path:路径
git remote add <name> <url>
git remote add origin Path
  • 添加多个远程仓库
git remote add origin url
git remote add origin1 url1
  • push
git push origin <master> 
git push origin1 <master>
  • 删除
git remote remove <name>
  • 修改
修改名称
git remote rename <old> <new>
修改地址
git remote set-url <name> <newurl> 
// git remote set-url origin git@example.instance.git
  • 查看
//简短信息 列出已经存在的远程分支
git remote
//地址信息
git remote -v
//详细信息
git remote show <name>

fetch

远程仓库有了新的更新，将这些更新取回本地，这时就要用到git fetch命令 它取回的代码对本地的开发代码没有影响,平时开发可能不会用到，但是 应该要明白原理，不是用不到，而是git的 命令合并操作 下面会说到。

//origin 仓库别名  master 分支
git fetch origin master

pull

git pull的默认行为是git fetch + git merge
git pull -r 即 git pull --rebase，相当于 git fetch + fit rebase

rebase/merge

rebase提供了一种在你合并代码到主干时一种有别于merge的方式,直接使用git merge合并代码时会出现多个分叉，并且有可能再你落后他人分支时会保留一个无意义的合并记录，这使得代码记录很乱，git 图表则会杂乱无章,git rebase则可提供一条完美的线性提交记录.

如下图所示，bugfix 分支是从 master 分支分叉出来的。 image.png

使用 rebase 之后： image.png

使用 merge 之后： image.png merge 会把两个分支合并在一起，形成一个新的 commit 提交

merge 和 rebase 实际上只是用的场景不一样

  • 比如 rebase,你自己开发分支一直在做,然后某一天，你想把主线的修改合到你的分支上,做一次集成,这种情况就用 rebase 比较好.把你的提交都放在主线修改的头上,

  • 如果用 merge，脑袋上顶着一笔 merge 的提交,你如果想回退你分支上的某个提交就很麻烦,还有一个重要的问题, rebase 的话,本来我的分支是从3拉出来的, rebase 完了之后,就不知道我当时是从哪儿拉出来的我的开发分支

  • 同样的,如果你在主分支上用 rebase , rebase 其他分支的修改,要是别人想看主分支上有什么历史,他看到的就不是完整的提交历史,这个历史已经被你篡改了

  • 下面看下具体的操作

  • merge 命令

两条分支 master develop

// 在master分支提交更改1
// 在 develop 分支提交更改 2 3

git checkout master
//合入develop
git merge develop
解决冲突后，`git push`，推送到远程一条带有merge记录的提交

//如果develop分支需要继续开发，并且需要master中新提交的代码

git checkout develop
执行`git merge master`把 master 合并到 develop 分支
  • rebase 特别注意 与 merge 思维 反向理解。a rebase b , b rebase a
// 在master分支提交更改1
// 在 develop 分支提交更改 2 3

git checkout master //切换到master分支
git rebase develop  //执行 rebase

//解决冲突 这里要注意 解决完冲突 执行  git add . 再 continue .
git add .
git rebase --continue

// 重复上述rebase步骤，直到 REBASE 消失

// 但是 如果想撤回
git rebase --abort //会放弃合并 回到rebase操作之前的状态

git rebase --skip //则会将引起冲突的commits丢弃掉（慎用！！）

merge可以准确的体现出时间线，rebase时间线容易混乱
rebase看起来简洁，可以做到只有一条树状图，而merge不会 俩种方法都可以，但要区分具体的使用场景，各有优秀的地方，但也都有缺陷，没有你想象中的完美\

综合：

  • 和远程仓库同步当前分支的时候使用 pull --rebase 的方式。
  • 合并分支的使用 feature rebase on master，master merge feature 的方式。

stash

这是用来存储的，使用场景如下

  • 想保存代码但又不想增加一个脏的提交,也就是不执行commite操作
  • stash是本地的，不会通过git push命令上传到git server上
  • 切分支或者什么，等等。场景很多，核心就是不执行无效的commite操作
  • 存储
git stash
git stash save 'message'
git stash save -a 'message'

在原分支 git stash save -a 'message',-a选项才会将新加入的代码文件同时放入暂存区。如果是以前就有了，那么就不用加-a，你加的话，会报错的。

  • 应用
//应用第一个储藏，但不会删除 默认最近一次保存的内容
git stash apply

//应用第一个储藏，会删除 默认最近一次保存的内容
git stash pop

// 指定应用保存的哪个记录 命令如下:
git stash apply stash@{num}: 应用列表中的储藏
git stash pop stash@{num}: 应用列表中的储藏
  • 查看
//显示Git栈内的所有备份，可以利用这个列表来决定从那个地方恢复。
git stash list 

//查看第一个储藏做了哪些改动(并不是改动详情)
git stash show

//查看其他储藏做了哪些改动
git stash show stash@{num}

//查看第一个储藏的改动
git stash show -p

//查看其他储藏做的改动
git stash show -p stash@{num}
  • 删除
//清空Git栈。此时使用git等图形化工具会发现，原来stash的那些节点都消失了
git stash clear

//删除以一个储藏
git stash drop

git stash drop stash@{num}: 删除stash list中的储藏，例如删除第二个：git stash drop stash@{1}

  • 切换回以前的分支后，如果你要恢复的是最近的一次改动，git stash pop，我想这是大家最常用的命令了吧; 如果有多次stash操作，那就通过git stash list查看stash列表，从中选择你想要pop的stash，运行命令git stash pop stash@{id}或者 git stash apply stash@{id}即可。

  • 删除stash; git stash drop stash@{id} 如果不加stash编号，默认的就是删除最新的，也就是编号为0的那个，加编号就是删除指定编号的stash。 当你都玩完了后，可以用git stash clear清理所有的缓存记录。

  • git stash pop 与 git stash apply 的区别; 这两个命令的区别。原来git stash pop stash@{id}命令会在执行后将对应的stash id 从stash list里删除，而 git stash apply stash@{id} 命令则会继续保存stash id。 一般来说你直接git stash pop stash@{id}就可以了，当然你如果想存下来，再后期的再次复原的话，可以用git satsh apply

.gitignore

有些文件希望 Git 忽略，不要在版本库中跟踪它，这个并不复杂，忽略的文件直接放进来就行了。记录下语法

*.a    //忽略所有以.a为后缀的文件
----------------------------------------------
*.a 
!lib.a
// 上面两个的意思是除了lib.a，其他所有的.a后缀的文件都忽略
----------------------------------------------
/aaa
// 只屏蔽当前目录下的aaa文件夹，不屏蔽 bbb/aaa (bbb文件夹下的aaa文件夹)
----------------------------------------------
build/
// 屏蔽build目录
----------------------------------------------
build/*
//屏蔽build目录下的所有文件，但不屏蔽build目录本身
----------------------------------------------
doc/*.txt
//屏蔽 doc/notes.txt，但不屏蔽doc/server/arch.txt
----------------------------------------------
doc/**/*.txt
//屏蔽doc目录下的所有的.txt文件，不论是 doc/notes.txt，还是doc/server/arch.txt，或者doc/server/index/log.txt
----------------------------------------------

log

git log -n 查看最近n条commit

git log --oneline 以简单的一行形式看commit历史
git log --graph 图形化查看提交历史
git log --graph --abbrev-commit 提交信息简写
git log --oneline --decorate --graph --stat decorate显示每个commit的引用(如:分支、tag等)
git log --author='desmond' 查找一位作者叫desmond的相关commit
git log -p test.txt 查看某个文件的提交记录，-p会将具体修改的情况一并显示

tag

git仓库的tag是git版本库的一个标记，指向某个commit id标记的快照记录指针,所以，标签也是版本库的一个快照

  • tag对应某次commit节点, 是一个点，是不可移动的。
  • branch对应一系列commit，是很多点连成的一根线，有一个HEAD 指针，是可以依靠 HEAD 指针移动的
  • 所以，两者的区别决定了使用方式，改动代码用branch ,不改动只查看用 tag

tag 和 branch 的相互配合使用，有时候起到非常方便的效果，例如：已经发布了 v1.0 v2.0 v3.0 三个版本，这个时候，我突然想不改现有代码的前提下，在 v2.0 的基础上加个新功能，作为 v4.0 发布。就可以检出 v2.0 的代码作为一个 branch ，然后作为开发分支。

  • 增
// 命令格式
git tag -a 标签名 -m "附注信息"

git tag -a v1.0 -m "v1.0版本"

// push 标签到远程仓库 
git push origin v1.0

// 在指定的 commit 打tag
git tag -a v0.1.1 9fbc3d0
  • 删
git tag -d tagName
// 举例
git tag -d v1.0
  • 查
git tag ：查看tag列表
git tag --list ：查看tag列表
git tag -l ：同理查看tag列表
  • 改
// 切换出分支 
git checkout v1.0

个人操作并非这样，个人认为没有必要那么麻烦，个人习惯于可视化工具操作，我是直接切分支作为版本标记，这样可视化，工具看起来一目了然。分支名就是版本名，哪个版本有问题的话 直接就切回哪个版本，直接改对应的需求或者bug然后 发版，或者跟别的分支合并，这个需要看具体的需求场景。

branch

git branch 查看分支
git branch -r 查看远程分支
git branch -a 列出本地与远程的分支
git branch newbranchname 创建新分支
git checkout branchname 切换分支
git checkout -b mybranchName 创建分支 并切换到次分支
git branch -d branchname 删除本地分支
git branch -d -r branchname 删除远程分支\

reset

改变HEAD指向，但不会创建新的分支

  • 代码回滚重置 会导致上一次的提交记录就没有了。 git reset --hard HEAD~1

--hard 会改变版本库的HEAD引用指向,缓存区/工作区的内容,执行后HEAD引用会指向commit指向的版本.缓存区/工作区内容都会被替换 --mixed 使用这个参数,工作区代码不会刷新,HEAD的引用指向会被改变,缓存区内容也会更新 --soft 只会改变HEAD引用的指向 git reset head. 再从缓存区移除

  • 问题：代码回滚后 --hard 想要再恢复怎么办呢？ git reset --hard + commitid 后 git log 可能看不到你提交的记录了，这时 git reflog就起作用了，记录你的操作记录，找到对应的id 回滚就可以了。

diff

  • git diff ： 对比工作区(未 git add)和暂存区(git add 之后) 
  • git diff --cached: 对比暂存区(git add 之后)和版本库(git commit 之后) 
  • git diff HEAD: 对比工作区(未 git add)和版本库(git commit 之后)

持续更新...

avatar
文章
阅读
粉丝