gitlab 基础操作

gitlab 基础操作

git commit：提交

图上为初始提交 C0 和其后可能包含某些有用修改的提交 C1。

git commit 后把这些修改保存成了一个提交记录 C2。C2 的父节点是 C1，父节点是当前提交中变更的基础。

Git Branch 分支名 (早建分支！多用分支！)

这是因为即使创建再多分的支也不会造成储存或内存上的开销，并且按逻辑分解工作到不同的分支要比维护那些特别臃肿的分支简单多了

git branch newImage

但是当前所在分支还是在master上 * 代表 当前所在分支

git checkout 分支名：切换当前所在分支
git commit

当前修改已经保存到新的分支里

git checkout -b 分支名 ：创建分支的同时切换到新的分支

git merge 合并的分支名

会自动提交新的修改记录相当于git commit了一次

把 bugFix 合并到 master 里

master 分支现在包含c3和c2分支即代表 master中是对代码库中所有的修改

git checkout bugFix:移到这个bugFix分支上
git merge master :将master分支包含到 bugFix分支中
即master，和bugFix分支都包含对代码库的全部修改

git rebase 要移到的分支名：

我们想要把 bugFix 分支里的工作直接移到 master 分支上。移动以后会使得两个分支的功能看起来像是按顺序开发，但实际上它们是并行开发的。

git rebase master

注意，提交记录 C3 依然存在（树上那个半透明的节点），而 C3’ 是我们 Rebase 到 master 分支上的 C3 的副本。

更新下master

git checkout master
git rebase bugFix

HEAD( 当前说在分支如 git checkout c4)

HEAD 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。
HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。
HEAD 通常情况下是指向分支名的（如 bugFix）。

相对引用

使用 ^ 向上移动 1 个提交记录
使用 ~ 向上移动多个提交记录，如 ~3

git checkout master^

也可用HEAD 作为相对引用的参照，
git checkout c3; HEAD指向c3节点
git checkout HEAD^;HEAD指向c2节点
git checkout HEAD^ ； 指向c1节点
git checkout HEAD^ ； 指向c0节点

git checkout HEAD~4

强制修改分支位置

git branch -f master HEAD~3

上面的命令会将 master 分支强制指向 HEAD 的第 3 级父提交。

git branch -f master HEAD~3

撤销变更

主要有两种方法用来撤销变更 —— 一是 git reset，还有就是 git revert

git reset 通过把分支记录回退几个提交记录来实现撤销改动。你可以将这想象成“改写历史”。git reset 向上移动分支，原来指向的提交记录就跟从来没有提交过一样。

git rest HEAD~1

git reset 很方便，但是这种“改写历史”的方法对大家一起使用的远程分支是无效的哦！为了撤销更改并分享给别人，我们需要使用 git revert

git revert HEAD

在我们要撤销的提交记录后面居然多了一个新提交！这是因为新提交记录 C2’ 引入了更改 —— 这些更改刚好是用来撤销 C2 这个提交的。也就是说 C2’ 的状态与 C1 是相同的。
revert 之后就可以把你的更改推送到远程仓库与别人分享啦。

整理提交记录

git cherry-pick <提交号>

将一些提交复制到当前所在的位置（HEAD）下面

这里有一个仓库, 我们想将 side 分支上的c2,c4工作复制到 master 分支

git cherry-pick c2 c4

交互式的 rebase

git rebase -i HEAD~4

对四个节点重新排顺序 并进行了复制

git tag v1 c1:在c1节点处建立标签v1

git describe :描述离你最近的锚点（也就是标签）

可以是任何能被 Git 识别成提交记录的引用，如果你没有指定的话，Git 会以你目前所检出的位置（HEAD）。

它输出的结果是这样的：

__g

tag 表示的是离 ref 最近的标签， numCommits 是表示这个 ref 与 tag 相差有多少个提交记录， hash 表示的是你所给定的 ref 所表示的提交记录哈希值的前几位。

当 ref 提交记录上有某个标签时，则只输出标签名称

git checkout HEAD~
git checkout HEAD^2
git checkout HEAD~2

也可用
git checkout HEAD~^2 ~2

git clone :创建远程仓库

远程分支有一个特别的属性，在你检出时自动进入分离 HEAD 状态

远程分支有一个命名规范 —— 它们的格式是:

/

一个名为 o/master 的分支，那么这个分支就叫 master，远程仓库的名称就是 o

Git Fetch 从远程仓库获取数据

完成了仅有的但是很重要的两步:

从远程仓库下载本地仓库中缺失的提交记录
更新远程分支指针(如 o/master)
git fetch 实际上将本地仓库中的远程分支更新成了远程仓库相应分支最新的状态。

git fetch 通常通过互联网（使用 http:// 或 git:// 协议) 与远程仓库通信。

git fetch 并不会改变你本地仓库的状态。它不会更新你的 master 分支，也不会修改你磁盘上的文件。

Git Pull

当远程分支中有新的提交时，你可以像合并本地分支那样来合并远程分支。也就是说就是你可以执行以下命令:

git cherry-pick o/master
git rebase o/master
git merge o/master

git fetch 和 git merge 的缩写！ ：将远程分支下载下来并合并

git fakeTeamwork 模拟团队合作

git fakeTeamwork

还可以指定提交的分支或是数量，只需要在命令后加上它们就可以了。

git fakeTeamwork foo 3

Git Push

git push 负责将你的变更上传到指定的远程仓库，并在远程仓库上合并你的新提交记录。一旦 git push 完成, 你的朋友们就可以从这个远程仓库下载你分享的成果了！

git push

Git Push 的参数

git push  :仓库，分支名

git push origin master
要同时为源和目的地指定 place 的话，只需要用冒号 : 将二者连起来就可以了：

git push origin :

git push origin foo^:master


如果你要推送到的目的分支不存在,Git 会在远程仓库中根据你提供的名称帮你创建这个分支

git push origin master:newBranch

git pull --rebase :就是 fetch 和 rebase 的简写

git pull --rebase
git push

远程服务器拒绝!(Remote Rejected)

如果你是在一个大的合作团队中工作, 很可能是master被锁定了, 需要一些Pull Request流程来合并修改。如果你直接提交(commit)到本地master, 然后试图推送(push)修改, 你将会收到这样类似的信息:

! [远程服务器拒绝] master -> master (TF402455: 不允许推送(push)这个分支; 你必须使用pull request来更新这个分支.)
解决办法
新建一个分支feature, 推送到远程服务器. 然后reset你的master分支和远程服务器保持一致, 否则下次你pull并且他人的提交和你冲突的时候就会有问题.

git branch -u :设置远程追踪分支

git branch -u o/master foo

这样 foo 就会跟踪 o/master 了。如果当前就在 foo 分支上, 还可以省略 foo：

git branch -u o/master

还有种方法
git checkout -b foo o/master;
也是创建哥foo分支跟踪 远程仓库

git操作学习网站，

https://learngitbranching.js.org/?demo=&locale=zh_CN