GIT

date

Feb 17, 2023

my-url

https://www.fpb.icu/article/git-8Hrdtqf70Nd8f5

slug

git-8Hrdtqf70Nd8f5

status

Published

category

IT笔记

summary

type

Post

Origin

URL

icon

password

GIT.md

22.1KB

md内无图片。

指令教程 collapsed:: true

创建仓库

git [command] --help
git init 创建版本库

版本库图示

collapsed:: true

collapsed:: true

3 collapsed:: true

管理修改 collapsed:: true

git add . 添加到暂存区
git commit -m " Submission Description " 提交到版本库。并留下快照
git log 查看commit历史，快照 collapsed:: true

git log --pretty=oneline 简化查看

git status查看一下状态：
git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别：

撤销修改 collapsed:: true

工作区 collapsed:: true

git status查看一下状态：
git checkout -- file可以丢弃工作区的修改： collapsed:: true

-很重要，没有-，就变成了“切换到另一个分支”的命令
命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：
一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
总之，就是让这个文件回到最近一次git commit或git add时的状态。

暂存区 collapsed:: true

git status查看一下状态：
git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区：

版本库 collapsed:: true

还没有把自己的本地版本库推送到[[#red]]==远程==。还记得Git是分布式版本控制系统吗？我们后面会讲到远程版本库，一旦你把stupid boss提交推送到远程版本库，你就真的惨了
工作区版本回退 collapsed:: true

git reset -- hard HEAD^ 回退到上一个版本–》 git log 看不到最新的 commit了–》 collapsed:: true

历史命令记录–》git reset --hard 1094a 再还原到最新版本
git reflog用来记录你的每一次命令–》git reset --hard 1094a 再还原到最新版本
HEAD 说明： collapsed:: true

HEAD 表示当前版本 HEAD^ 上一个版本 HEAD^^ 上上一个版本 HEAD^^^ 上上上一个版本以此类推...可以使用～数字表示 HEAD~0 表示当前版本 HEAD~1 上一个版本 HEAD^2 上上一个版本 HEAD^3 上上上一个版本以此类推...

删除文件 collapsed:: true

版本库 collapsed:: true

$ git rm test.txtrm 'test.txt'$ git commit -m "remove test.txt"[master d46f35e] remove test.txt 1 file changed, 1 deletion(-) delete mode 100644 test.txt

从版本库恢复 collapsed:: true

$ rm test.txt //删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本： $ git checkout -- test.txt

Sydney collapsed:: true

git add . 是一个命令，用于将工作区的所有修改和新增的文件添加到暂存区（index），但是不包括删除的文件 1 2。
如果你想让版本库删除已经删除的文件，你有两种方法：
一是使用 git rm 命令，它可以从暂存区和工作区同时删除文件。有两个选项，–cached 表示只从暂存区删除，不影响物理文件；–f 表示强制从暂存区和物理文件都删除 3 2 4。例如：
git rm --cached test.txt
git rm --f test.txt

远程仓库 collapsed:: true

链接 Github
1.生成 ssh key collapsed:: true

pkg upgrade && pkg update pkg install openssh ssh-keygen -t ed25519 -C "[email protected]" //library "libcrypto.so.3" not found: needed by main executable cat .ssh/id_ed25519.pub # SSH Key 内容

git config –global user.email “[email protected]” git config –global user.name “birdy@note10”

GH_USER= your github username GH_REPO= your github repository

git clone [email protected]:GHUSER/GH_REPO.git

$ git remote add origin [email protected]:michaelliao/learngit.git

把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。
由于远程库是空的，我们第一次推送master分支时，加上了u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
$ git push origin master

3.克隆 collapsed:: true

git clone克隆一个本地库： collapsed:: true

$ git clone [email protected]:michaelliao/gitskills.git

Git支持多种协议，包括https，但ssh协议速度最快。

3.删除远程库 collapsed:: true

用git remote -v查看远程库信息： collapsed:: true

$ git remote -v origin [email protected]:michaelliao/learn-git.git (fetch) origin [email protected]:michaelliao/learn-git.git (push)

$ git remote rm origin //此处的“删除”其实是解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。要真正删除远程库，需要登录到GitHub，在后台页面找到删除按钮再删除。

其他 collapsed:: true

3. 同步脚本及快捷按钮 collapsed:: true

在 Termux 跟目录中，编写脚本 pull.sh 、push.sh 和 log.sh 在手机桌面可添加 pull.sh 、push.sh 和 log.sh 的小组件按钮。

给予执行权限：chmod +x pull.sh push.sh log.sh ，配置小组件

4. 忽略同步冲突文件 collapsed:: true

添加 .gitgnore 文件忽略部分文件目前防止同步冲突，

若中途添加 .gitgnore ，需删除提交记录

电脑和手机不要同时编辑
编辑即 push
换终端编辑前 pull

分支管理 collapsed:: true

原理指针 collapsed:: true

分开–》合并
HEAD指向的就是当前 master master才是指向提交的 collapsed:: true

HEAD │ │ ▼ master │ │ ▼ ┌───┐ ┌───┐ ┌───┐ │ │───▶│ │───▶│ │ └───┘ └───┘ └───┘

创建新的分支，例如dev collapsed:: true

Git新建了一个指针叫dev，指向master相同的提交
HEAD指向dev，就表示当前分支在dev上 collapsed:: true

master │ │ ▼ ┌───┐ ┌───┐ ┌───┐ │ │───▶│ │───▶│ │ └───┘ └───┘ └───┘ ▲ │ │ dev ▲ │ │ HEAD

对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变 collapsed:: true

master │ │ ▼ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │ │───▶│ │───▶│ │───▶│ │ └───┘ └───┘ └───┘ └───┘ ▲ │ │ dev ▲ │ │ HEAD

dev合并到master上 collapsed:: true

直接把master指向dev的当前提交，就完成了合并：
HEAD │ │ ▼ master │ │ ▼ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │ │───▶│ │───▶│ │───▶│ │ └───┘ └───┘ └───┘ └───┘ ▲ │ │ dev

删除dev分支 collapsed:: true

删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支
HEAD │ │ ▼ master │ │ ▼ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │ │───▶│ │───▶│ │───▶│ │ └───┘ └───┘ └───┘ └───┘

创建合并 collapsed:: true

创建分支：git branch <name>
git checkout -b dev 创建dev分支，并切换到dev分支： collapsed:: true

git checkout命令加上b参数表示创建并切换，相当于以下两条命令： collapsed:: true

$ git branch dev $ git checkout dev

git branch命令查看当前分支： collapsed:: true

git branch命令会列出所有分支，当前分支前面会标一个号。

git checkout master 切换回master分支： collapsed:: true

git merge dev 分支合并到master分支上：
git branch -d dev删除dev分支
git switch -c dev创建并切换到新的dev分支
git switch master 切换到已有的master分支 collapsed:: true

小结 collapsed:: true

查看分支：git branch
创建分支：git branch <name>
切换分支：git checkout <name>或者git switch <name>
创建+切换分支：git checkout -b <name>或者git switch -c <name>
合并某分支到当前分支：git merge <name>
删除分支：git branch -d <name>

解决冲突 collapsed:: true

master分支和feature1分支各自都分别有新的提交 collapsed:: true

HEAD │ │ ▼ master │ │ ▼ ┌───┐ ┌─▶│ │ ┌───┐ ┌───┐ ┌───┐ │ └───┘ │ │───▶│ │───▶│ │──┤ └───┘ └───┘ └───┘ │ ┌───┐ └─▶│ │ └───┘ ▲ │ │ feature1

git merge feature1 发现冲突
git status也可以告诉我们冲突的文件
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改如下后保存： collapsed:: true

HEAD │ │ ▼ master │ │ ▼ ┌───┐ ┌───┐ ┌─▶│ │───▶│ │ ┌───┐ ┌───┐ ┌───┐ │ └───┘ └───┘ │ │───▶│ │───▶│ │──┤ ▲ └───┘ └───┘ └───┘ │ ┌───┐ │ └─▶│ │──────┘ └───┘ ▲ │ │ feature1

git log --graph --pretty=oneline --abbrev-commit 分支合并图。
删除feature1分支：

分支管理策略 collapsed:: true

Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
准备合并dev分支，请注意-no-ff参数，表示禁用Fast forward：
git merge --no-ff -m "merge with no-ff" dev
用git log看看分支历史： collapsed:: true

分支策略 collapsed:: true

BUG分支 collapsed:: true

为何？ collapsed:: true

纯属讨论, 个人认为这个跟设计理念有些关系.
如果有些bug很紧急, 而你当前的修改只做到一半, 导致工程都无法启动起来.
这时当然是可以 git commit 或者 git stash.
那两者有什么区别?
git commit 会在 git log 里面留下一次 log, 而你push之后别人是可以回退到你这个版本的, 不论什么原因, 如果别人到了你这个版本, 发现连工程都启动不起来, 自然会有很多疑问.
因此一次良好的 git commit 应该不要破坏工程的稳定性才对.
所以你不能把做到一半的代码进行 git commit.
(当然以上都是一些很理想的情况, 反正 git commit 也可以, 又不是不能用

暂存工作区，而不提交commit collapsed:: true

stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
用git status查看工作区，就是干净的
刚才的工作现场存到哪去了？用git stash list命令看看：
是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了：

然后创建新的分支，commit改bug
要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。注意：我们只想复制4c805e2 fix bug 101这个提交所做的修改，并不是把整个master分支merge过来。
Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支： collapsed:: true

$ git branch * dev master $ git cherry-pick 4c805e2 [master 1d4b803] fix bug 101 1 file changed, 1 insertion(+), 1 deletion(-)
Git自动给dev分支做了一次提交，注意这次提交的commit是1d4b803，它并不同于master的4c805e2，因为这两个commit只是改动相同，但确实是两个不同的commit。用git cherry-pick，我们就不需要在dev分支上手动再把修bug的过程重复一遍。

有些聪明的童鞋会想了，既然可以在master分支上修复bug后，在dev分支上可以“重放”这个修复过程，那么直接在dev分支上修复bug，然后在master分支上“重放”行不行？当然可以，不过你仍然需要git stash命令保存现场，才能从dev分支切换到master分支。

Feature分支 collapsed:: true

git **switch** -c feature-vulcan
git branch -D feature-vulcan

多人协作 collapsed:: true

查看远程库的信息，用git remote：
用git remote -v显示更详细的信息：
推送分支 collapsed:: true

推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：
$ git push origin master
如果要推送其他分支，比如dev，就改成：
$ git push origin dev

抓取分支 collapsed:: true

从远程库clone时，默认情况下，你的小伙伴只能看到本地的master分支。不信可以用git branch命令看看：
要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支： collapsed:: true

$ git checkout -b dev origin/dev

推送冲突 collapsed:: true

先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：
git pull也失败了，原因是没有指定本地dev分支与远程origin/dev分支的链接，根据提示，设置dev和origin/dev的链接： collapsed:: true

$ git branch *--set-upstream-to=origin/dev dev*

小结 collapsed:: true

因此，多人协作的工作模式通常是这样：
首先，可以试图用git push origin <branch-name>推送自己的修改；
如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；
如果合并有冲突，则解决冲突，并在本地提交；
没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！这就是多人协作的工作模式，一旦熟悉了，就非常简单。

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

小结
查看远程库信息，使用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，如果有冲突，要先处理冲突。

标签管理

标签是指向commit的死指针，分支是指向commit的活指针
创建标签 collapsed:: true

敲命令git tag <name>就可以打一个新标签： collapsed:: true

$ git tag v1.0

可以用命令git tag查看所有标签： collapsed:: true

$ git tag v1.0

方法是找到历史提交的commit id，然后打上就可以了： collapsed:: true

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

对add merge这次提交打标签，它对应的commit id是f52c633，敲入命令： collapsed:: true

$ git tag v0.9 f52c633

标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息：
$ git **show** v0.9
标签不是按时间顺序列出，而是按字母排序的。可以用git show <tagname>查看标签信息：

$ git **show** v0.9

还可以创建带有说明的标签，用a指定标签名，m指定说明文字：

$ git tag -a v0.1 -m "version 0.1 released" 1094adb

注意：标签总是和某个commit挂钩。如果这个commit既出现在master分支，又出现在dev分支，那么在这两个分支上都可以看到这个标签。

操作标签