目录

git

[TOC]

CRLF将被LF替换问题

http://img.cana.space/picStore/20211005133744.png

解决步骤:

  1. 安装dos2unix

    https://macappstore.org/dos2unix/

  2. 转换文件

    http://img.cana.space/picStore/20211005134051.png

  3. 使用说明:https://www.jianshu.com/p/d2e96b2ccab9

git合并冲突后回退

多人合作开发时,将feature合到dev产生冲突,是别人的需要别人去解决冲突,此时可以放弃这次merge让别人去解决即可

1
$ git merge --abort

git stash用法总结

https://www.cnblogs.com/zndxall/archive/2018/09/04/9586088.html

常用git stash命令:

(1)git stash save “save message” : 执行存储时,添加备注,方便查找,只有git stash 也要可以的,但查找时不方便识别。

(2)git stash list :查看stash了哪些存储

(3)git stash show :显示做了哪些改动,默认show第一个存储,如果要显示其他存贮,后面加stash@{$num},比如第二个 git stash show stash@{1}

(4)git stash show -p : 显示第一个存储的改动,如果想显示其他存存储,命令:git stash show stash@{$num} -p ,比如第二个:git stash show stash@{1} -p

(5)git stash apply :应用某个存储,但不会把存储从存储列表中删除,默认使用第一个存储,即stash@{0},如果要使用其他个,git stash apply stash@{$num} , 比如第二个:git stash apply stash@{1}

(6)git stash pop :命令恢复之前缓存的工作目录,将缓存堆栈中的对应stash删除,并将对应修改应用到当前的工作目录下,默认为第一个stash,即stash@{0},如果要应用并删除其他stash,命令:git stash pop stash@{$num} ,比如应用并删除第二个:git stash pop stash@{1}

(7)git stash drop stash@{$num} :丢弃stash@{$num}存储,从列表中删除这个存储

(8)**git stash clear** :删除所有缓存的stash

git撤销本地修改

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
如果在修改时发现修改错误,而要放弃本地修改时:

一,未使用 git add 缓存代码时:

可以使用 git checkout -- filepathname (比如: git checkout -- readme.md  ,不要忘记中间的 “--” ,不写就成了检出分支了!!)。

放弃所有的文件修改可以使用 git checkout .  命令。

此命令用来放弃掉所有还没有加入到缓存区(就是 git add 命令)的修改:内容修改与整个文件删除。

但是此命令不会删除掉刚新建的文件。因为刚新建的文件还没已有加入到 git 的管理系统中。所以对于git是未知的。自己手动删除就好了。

或者使用下面的命令(git clean命令只适用于当前文件夹,记得切换文件夹):

# 删除 untracked files

git clean -f

# 连 untracked 的目录也一起删掉

git clean -df

 

二,已经使用了  git add 缓存了代码:

可以使用  git reset HEAD filepathname (比如: git reset HEAD readme.md)来放弃指定文件的缓存,放弃所有的缓存可以使用 git reset HEAD . 命令。

此命令用来清除 git  对于文件修改的缓存。相当于撤销 git add 命令所在的工作。在使用本命令后,本地的修改并不会消失,而是回到了如(一)所示的状态。继续用(一)中的操作,就可以放弃本地的修改。

 

三,已经用 git commit  提交了代码:

可以使用 git reset --hard HEAD^ 来回退到上一次commit的状态。此命令可以用来回退到任意版本:git reset --hard  commitid 

你可以使用 git log 命令来查看git的提交历史。

git log命令总结

•    git log --all 查看所有分支的历史

•    git log --all --graph 查看图形化的 log 地址

•    git log --oneline 查看单行的简洁历史。

•    git log --oneline -n4 查看最近的四条简洁历史。

•    git log --oneline --all -n4 --graph 查看所有分支最近 4 条单行的图形化历史。

•    git help --web log 跳转到git log 的帮助文档网页

 

 

四,git提交命令

git add -u:将文件的修改、文件的删除,添加到暂存区。

将工作空间被修改和被删除的文件添加到暂存区(不包含没有纳入Git管理的新增文件)

git add .:将文件的修改,文件的新建,添加到暂存区。

git add -A:将文件的修改,文件的删除,文件的新建,添加到暂存区。

工作中一般是用到 git add . 或者 git add -A,。今天学习更进一步解了 git add -u 以及他们之间的区别

git add -A相对于git add -u命令的优点 : 可以提交所有被删除、被替换、被修改和新增的文件到数据暂存区,而git add -u 只能操作跟踪过的文件

git add -A 等同于git add -all

 

总结:

·  git add -A  提交所有变化

·  git add -u  提交被修改(modified)和被删除(deleted)文件,不包括新文件(new)

·  git add .  提交新文件(new)和被修改(modified)文件,不包括被删除(deleted)文件

 

修改重命名文件:

git mv files Files 只需要一个操作

mac安装git-gui

1
2
3
4
git clone https://github.com/prati0100/git-gui.git
cd git-gui
make
make install

git rebase操作记录

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
1. git log 查看提交日志
2. //以下命令表示合并 6f9b8ecc 往后的 commit(不包括 6f9b8ecc)
git rebase -i 6f9b8ecc
3. 将 被合并的分支 前面的 pick 改为 s 
4. 保存退出后进入提交信息修改界面
5. 改完之后, 本地commit已经合并成了一次提交,此时需要本地push, 分两种情况:
	5.1.feature分支只有你一个人在开发
		直接 git push --force
	5.2. feature分支有多人开发
		git push --force-with-lease origin feature 
		使用该命令在强制覆盖前会进行一次检查如果其他人在该分支上有提交会有一个警告,此时可以避免福改代码的风险。
建议:不管当前分支是否只有自己在使用,在rebase之后,需要强制推送到远端分支时,使用  git push --force-with-lease origin feature  参数来保证分支安全。

git add 与 git commit -am

原文地址

git add命令是个多功能命令,根据目标文件的状态不同,此命令的效果也不同:可以用它开始跟踪新文件,或者把已跟踪的文件放到暂存区,还能用于合并时把有冲突的文件标记为已解决状态等

我们需要用git add命令来跟踪新文件,但如果使用git commit -am可以省略使用git add命令将已跟踪文件放到暂存区的功能,但是不会对新文件起作用。

远程分支版本回退

  1. git clone 远程分支master
  2. git checkout 提交错误的分支
  3. git reflog
  4. 根据操作日志查看想要回退的版本号(或远程提交记录里的版本号)
  5. git reset –hard 需要回退到的版本号
  6. git push -f

upstream

建立分支与分支之间的流通道

git push -u和git branch –set-upstream-to指令之间的区别

git push -u origin mybranch1 相当于 git push origin mybranch1 + git branch –set-upstream-to=origin/mybranch1 mybranch1

- - depth 1

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
当项目过大时,git clone时会出现error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out的问题
解决方法很简单,在git clone时加上--depth=1即可解决

克隆的项目只包含最近的一次commit的一个分支,体积很小,即可解决文章开头提到的项目过大导致Timeout的问题,但会产生另外一个问题,他只会把默认分支clone下来,其他远程分支并不在本地,所以这种情况下,需要用如下方法拉取其他分支:

$ git clone --depth 1 https://github.com/dogescript/xxxxxxx.git
$ git remote set-branches origin 'remote_branch_name'
$ git fetch --depth 1 origin remote_branch_name
$ git checkout remote_branch_name

克隆的时候也可以指定版本,例如
git clone --depth=1 -b master https://github.com/apache/xxxx.git xxxProject

清空github仓库而不是删除重新创建

1
2
3
4
5
6
7
8
9
-- Remove the history from
rm -rf .git
-- recreate the repos from the current content only
git init
git add .
git commit -m "Initial commit"
-- push to the github remote repos ensuring you overwrite history
git remote add origin git@github.com:lienhui68/lienhui68.github.io.git
git push -u --force origin master

commit完成之后再修改沿用上次commit log

重新git add, commit改成git commit –amend, 这样就还是一条git log信息

反向忽略

1
2
3
* #忽略所有
!*/ # 取消忽略*/
!.vim/plugin/*

参考:http://www.voidcn.com/article/p-dlwytwql-btn.html

Summary

本节摘取于微信公众号码农田小齐, 作者小齐本齐

CVCS和DVCS

  1. 集中化版本控制系统 Centralized Version Control Systems (CVCS), 比如CVS, Subversion, Perforce, etc. https://gitee.com/lienhui68/picStore/raw/master/null/20200706191818.png 这种模式相对本地版本控制系统是有所改进的,但是缺点也很明显,如果服务器宕机,那么轻则耽误工作、重则数据丢失。于是分布式版本控制系统应运而生。

  2. 分布式版本控制系统 Distributed Version Control Systems (DVCS), 比如:Git, Mercurial, Bazaar, etc. 分布式的版本控制系统会把代码仓库完整地镜像下来,这样任何一个服务器发生故障,都可以用其他的仓库来修复。

什么叫“把代码仓库完整地镜像下来” CVCS 每个版本存放的是当前版本与前一个版本的差异,因此也被称作基于差异的版本控制 (delta-based); Git 存储的是所有文件的一个快照 (snapshot),如果有的文件没有修改,那就只保留一个 reference 指向之前存储的文件。

更进一步,这种模式可以更方便的和不同公司的人进行同一项目的开发,因为两个远程代码仓库可以交互,这在之前的集中式系统中是无法做到的。

Git的数据模型

  1. 什么是快照 (snapshot) 首先我们来学两个 Git 中的术语:
  • blob, 就是单个的文件;
  • tree, 就是一个文件夹。

快照则是被追踪的最顶层的树。 比如我的“公众号”文件夹的这么一个结构: https://gitee.com/lienhui68/picStore/raw/master/null/20200706192555.png 那么一个快照就是追踪的“公众号”这颗树。

  1. 本地库的数据模型 Git 记录了每个快照的 parent,也就是当前这个文件夹的上一个版本。 那么快照的迭代更新的过程就可以表示为一个有向无环图。 https://gitee.com/lienhui68/picStore/raw/master/null/20200706192656.png 每个快照其实都对应了一次 commit。
1
2
3
4
5
6
class commit {
  array<commit> parents
  String author
  String message
  Tree snapshot
}

这就是 Git 的数据模型。 blob, tree, snapshot 其实都一样,它们在 Git 中都是对象,都可以被引用或者被搜索,会基于它们的 SHA-1 hash 进行寻址。

git cat-file -t: 查看每个 SHA-1 的类型; git cat-file -p: 查看每个对象的内容和简单的数据结构。

但是通过这个哈希值来搜索也太不方便了,毕竟这是一串 40 位的十六进制字符,就是第二部分 git log 里输出的那个编码。 因此,Git 还给了一个引用 reference。比如,我们常见的 HEAD 就是一个特殊的引用。本地库就是由 对象 和 引用 构成的,或者叫 Repositories. 在硬盘上,Git 只存储 对象 和 引用,所有的 Git 命令都对应提交一个快照。

git命令

git reflog 显示单行log git reset –hard xxx 三个区都同步,都跳到这个 xxx 的版本上。 git reset –soft xxx 工作区和暂存区不同步,本地仓库跳到这个版本 git reset –mixed xxx 暂存区同步 git pull = fetch + merge git fetch 这个操作是将远程库的数据下载到本地库,但是工作区中的文件没有更新。 https://gitee.com/lienhui68/picStore/raw/master/null/20200706193829.png merge 是 git pull 默认的选项,合并其实还有另外一种方法:rebase,中文叫做变基。 git rebase rebase 的作用更多的是来整合分叉的历史,可以将某个分支上的所有修改都移到另一分支上,就像是变了基底。 git help eg:git help pull