哪些网站可以做gif,wordpress怎么把分类栏目静态,可信网站认证 技术支持单位,酒店网站的设计摘要1. 安装、Git 环境配置
1.1 安装 Git
官方版本可以在 Git 官方网站下载#xff1a;打开 https://git-scm.com/download/win#xff0c;选择相应版本即可。
Git 安装完成后#xff0c;可以在开始菜单中看到 Git 的三个启动图标#xff08;Git Bash、Git CMD、Git GUI打开 https://git-scm.com/download/win选择相应版本即可。
Git 安装完成后可以在开始菜单中看到 Git 的三个启动图标Git Bash、Git CMD、Git GUI。Git Bash 是 Git 配套的一个控制台在空白处右键点击 Open Git Bash here 即可开始使用 Git。 1.2 Git 环境配置通过 git config 命令配置用户信息
安装完 Git 之后要做的第一件事就是设置你的用户名和邮件地址。 这一点很重要因为每一个 Git 提交都会使用这些信息它们会写入到你的每一次提交中不可更改。
1.2.1 配置用户名和邮件地址 git config --global user.name abigailqin git config --global user.email abigailqincsdn.net 注意git config --global user.name xxxx要有双引号。如果使用了 --global 选项那么该命令只需要运行一次因为之后无论你在该系统上做任何事情 Git 都会使用那些信息。 如果想针对特定项目使用不同的用户名称与邮件地址时可以在那个项目目录下运行没有 --global 选项的命令来配置。
1.2.2 查看配置
1使用 git config --list 命令列出 Git 当前能找到的所有配置 2使用 git config key 检查 Git 的某一项配置。 1.3 SSH Key
SSH Key 是一种用于在 Git 版本控制系统中进行安全身份验证的机制。它是一对密钥包括公钥和私钥公钥存储在 Git 服务器上而私钥则存储在用户的本地计算机上。Git SSH Key 通过使用加密技术确保只有具有正确私钥的用户才能访问 Git 仓库。SSH Key 允许用户通过 SSH 连接到 Git 服务器而不需要输入密码这种身份验证方式比传统的基于用户名和密码的身份验证更加安全和可靠。
向 Git 服务器提供 SSH 公钥的过程在所有操作系统上都是相似的首先需要确认自己是否已经拥有密钥。 默认情况下用户的 SSH 密钥存储在其 ~/.ssh 目录下进入该目录并列出其中内容便可以快速确认自己是否已拥有密钥。 我们需要寻找一对以 id_dsa 或 id_rsa 命名的文件其中一个带有 .pub 扩展名。 .pub 文件是公钥另 一个则是私钥。 如果找不到这样的文件或者根本没有 .ssh 目录可以通过运行 ssh-keygen 程序来创建它们。首先 ssh-keygen 会确认密钥的存储位置默认是 .ssh/id_rsa然后它会要求你输入两次密钥口令如果你不想在使用密钥时输入口令将其留空即可。
现在进行了上述操作的用户需要将各自的公钥发送给 Git 服务器管理员假设服务器正在使用基于公钥的 SSH 验证设置复制 .pub 文件内容并将其通过邮件发送即可。
1.4 定制 Git 环境
Git 自带 git config 工具来帮助设置控制 Git 外观和行为的配置变量。
这些 Git 配置变量存储在三个不同的位置
1. /etc/gitconfig 文件Git 安装目录: 包含系统上每一个用户及他们仓库的通用配置。 如果在执行 git config 时带上 --system 选项那么它就会读写该文件中的配置变量 由于它是系统配置文件因此你需要管理员或超级用户权限来修改它。
2. ~/.gitconfig 或 ~/.config/git/config 文件只针对当前用户。 可以传递 --global 选项让 Git 读写此文件这会对你系统上所有的仓库生效。
3. 当前使用仓库的 Git 目录中的 config 文件即 .git/config针对该仓库。 可以传递 --local 选项让 Git 强制读写此文件虽然默认情况下用的就是它当然你需要进入这个 Git 仓库中才能让该选项生效。
每一个级别会覆盖上一级别的配置所以 .git/config 的配置变量会覆盖 /etc/gitconfig 中的配置变量。
使用 git config --list --show-origin 查看所有的配置以及它们所在的文件。 1.3.1 忽略文件 .gitignore
在 Git 工作区的根目录下与.git 目录在同一级别创建一个特殊的 .gitignore 文件然后把要忽略的文件名填进去Git 在每次进行提交的时候就会自动忽略这些文件。我们一般不需要从头开始编辑 .gitignore 文件已经有各种现成的种配置文件只需要组合一下就可以使用了。所有配置文件可以直接在线浏览
Python.gitignore · master · GitCode / Gitignore · GitCode
示例 忽略文件的原则 忽略操作系统自动生成的文件比如缩略图等忽略编译生成的中间文件、可执行文件等也就是如果一个文件是通过另一个文件自动生成的那自动生成的文件就没必要放进版本库比如Java编译产生的.class文件忽略带有敏感信息的配置文件比如存放口令的配置文件。 假设你在 Windows 下进行 Python 开发
Windows 会自动在有图片的目录下生成隐藏的缩略图文件如果有自定义目录目录下会有 Desktop.ini 文件需要忽略上述 Windows 自动生成的垃圾文件此外还需忽略 Python 编译产生的.pyc、.pyo、dist等文件或目录再加上你自己定义的文件得到一个完整的 .gitignore 文件内容如下最后一步就是把 .gitignore 也提交到 Git就完成了。
.gitignore
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build# My configurations:
db.ini
deploy_key_rsa
1.3.2 强制添加被忽略文件 git add -f
有时候可能想添加一个文件到 Git但发现添加不了因为这个文件被 .gitignore 忽略了。如果你确实想添加该文件可以用 -f 强制添加到 Git。 $ git add -f App.class 尽管可以用 git add -f 强制将此文件添加进去但建议你添加一条例外规则把指定文件排除在 .gitignore 规则外写法是 !文件名。
.gitignore
# 排除所有 .class 文件
*.class# 不排除 .App.class 文件
!App.class
如果觉得添加不了是 .gitignore 写得有问题需要找出来到底哪个规则写错了可以用 git check-ignore 命令检查。
$ git check-ignore -v App.class
.gitignore:3:*.class App.class# 返回结果说明.gitignore 的第3行规则忽略了该文件因此修订第3行规则即可。
1.3.3 配置别名 git config --global alias.xx yyyy
使用 Git 命令时可以通过配置别名的方式简化命令。比如给 git status 命令配置一个别名 git st输入 git st 就比输入 git status 简单方便很多。下述这行命令就是告诉 Git以后 st 就表示 status--global参数是全局参数表示这个命令在这台电脑的所有 Git 仓库下都可以使用。 $ git config --global alias.st status 示例-1用 ci 表示 commit
$ git config --global alias.ci commit$ git ci -m sth.
示例-2用 last 表示 log -1git last 表示 git log -1即显示最近一次的提交
$ git config --global alias.last log -1$ git last
示例-3用 unstage 表示 reset HEADgit unstage file 即为 git reset HEAD file撤销暂存区的修改。
1.5 获取帮助
如果在使用 Git 时需要获取帮助可以使用 help 命令找到 Git 命令的使用手册 $ git help verb $ git verb --help 例如要想获得 config 命令的手册执行 git help config 命令或 git config --help 命令后将跳转到使用手册对应页 2. Git 仓库
2.1 工作目录working tree\working directory、暂存区域staging area\index和 Git 仓库repository\git repository
Git 项目有三个工作区域的概念工作目录、暂存区域和 Git 仓库。 Git 仓库目录是 Git 用来保存项目的元数据和对象数据库的地方。 这是 Git 中最重要的部分从其它计算机克隆仓库时拷贝的就是这里的数据。工作目录是对项目的某个版本独立提取出来的内容是你在电脑里能看到的目录。 这些从 Git 仓库的压缩数据库中提取出来的文件放在磁盘上供你使用或修改。暂存区域是一个文件保存了下次将提交的文件列表信息一般在 Git 仓库目录中有时候也被称作 ‘索引’index不过一般说法还是叫暂存区域staging area。 基本的 Git 工作流程如下 在工作目录中修改文件。暂存文件将文件的快照放入暂存区域。提交更新找到暂存区域的文件将快照永久性存储到 Git 仓库目录。 如果 Git 目录中保存着的特定版本文件就属于已提交状态。 如果作了修改并已放入暂存区域就属于已暂存状态。 如果自上次取出后作了修改但还没有放到暂存区域就是已修改状态。
在你的工作目录下的每一个文件都不外乎这两种状态已跟踪或未跟踪。 已跟踪的文件是指那些被纳入了版本控制的文件在上一次快照中有它们的记录在工作一段时间后它们的状态可能处于未修改已修改或已放入暂存区。 工作目录中除已跟踪文件以外的所有其它文件都属于未跟踪文件它们既不存在于上次快照的记录中也没有放入暂存区。 初次克隆某个仓库的时候工作目录中的所有文件都属于已跟踪文件并处于未修改状态。 2.2 使用 git init 在现有目录中初始化仓库
git init 用于在当前目录下初始化一个新的 Git 仓库。初始化后会在当前目录下创建一个名为 .git的隐藏文件夹其中包含了 Git 仓库的所有元数据和历史记录。执行该命令后当前目录下的所有文件和子目录都会被纳入 Git 的版本控制中你可以开始添加、修改和提交文件到 Git 仓库。 2.3 使用 git clone 克隆现有的仓库
语法git clone 远程仓库地址例如如果要将 GitHub 上的一个仓库复制到本地可以使用以下命令git clone https://github.com/username/repo.git其中username 是 GitHub 用户名repo 是仓库名称。
3. 基础操作
3.1 检查文件状态 git status
要查看哪些文件处于什么状态可以用 git status 命令。 该命令显示了当前所在分支当前的分支名是 master这是默认的分支名并告诉你当前工作目录中哪些文件被修改了、哪些文件被添加或删除了、哪些文件已经被暂存了等等。
git status 命令的输出十分详细但其显示结果有些繁琐。 可以使用 git status -s 命令或 git status --short 命令得到更为紧凑的格式输出示例 新添加的未跟踪文件前面有 ?? 标记新添加到暂存区中的文件前面有 A 标记修改过的文件前面有 M 标记M 有两个可以出现的位置出现在右边的 M 表示该文件在工作区被修改了且没放入暂存区出现在靠左边的 M 表示该文件在工作区被修改了并放入了暂存区MM表示此文件在工作区被修改并提交到暂存区后又在工作区中被修改了所以在暂存区和工作区都有该文件被修改了的记录。 3.2 跟踪新文件、暂存已修改文件git add
git add 是一个多功能命令可以用它开始跟踪新文件或者把已跟踪的文件放到暂存区还能用于合并时把有冲突的文件标记为已解决状态等。 将这个命令理解为 “添加内容到下一次提交中” 而不是 “将一个文件添加到项目中” 要更加合适。
3.2.1 跟踪新文件 git add pathspec… git add 命令使用文件或目录的路径作为参数如果参数是目录的路径该命令将递归地跟踪该目录下的所有文件。使用 add 后可以再用 git status 查看一下文件状态只要在 Changes to be committed 这行下面的就说明是已暂存状态。 可以在 git add 命令后面跟上多个文件名用空格隔开。 3.2.2 暂存已修改的文件 git add pathspec…
出现在 Changes not staged for commit 下面的文件已跟踪但内容发生了变化还没有放到暂存区需要运行 git add 命令暂存这次更新。
如果在运行了 git add 之后又作了修改需要重新运行 git add 把最新版本重新暂存起来。
3.3 撤销工作区修改或撤销暂存操作 git restore pathspec…
3.3.1 撤销工作区未暂存的修改git restore pathspec…
git restore pathspec... 可以将工作区指定的文件或目录恢复成和暂存区一致的状态。如果指定的文件或目录在暂存区中已经有了修改那么这些修改也会被覆盖掉恢复成暂存区中的版本pathspec… 表示需要恢复的文件或目录。使用 git restore 命令会直接覆盖当前工作区的文件因此请谨慎使用。
假如你在工作区修改了 temp.txt 文件的内容但还没有将修改暂存到暂存区如果想撤销修改可以使用 git restore 命令 如果想要将文件或目录恢复到指定的提交状态可以使用 git restore 命令加上 --source 参数
git restore --sourcecommit pathspec…
3.3.2 保留工作区修改撤销暂存git reset 可以实现一样的功能git restore --staged pathspec… git restore --staged pathspec… 命令可将暂存区指定的文件恢复到最新的提交状态HEAD撤销已暂存但未提交的更改但不会不修改工作区文件内容。
在 Git 中用 HEAD 表示当前仓库版本也就是最新的提交上一个版本是 HEAD^上上一个版本是 HEAD^^当然往上100个版本写100个^比较容易数不过来所以写成 HEAD~100。 使用 --source 将暂存区恢复到指定的提交状态不改动工作区
git restore --sourcecommit --staged pathspec…
下面的场景中先对两个文件使用 mv 命令执行重命名操作并把两次操作记录到暂存区。 如果想把这两次操作分两次提交想撤销暂存区中的 renamed temp2.txt - temp.txt可使用 --staged恢复暂存区内容。HEAD 对应的暂存区中没有 temp.txt执行 restore temp.txt 命令后 temp.txt 变成 untrackedHEAD 对应的暂存区中存在 temp2.txt 文件但工作区目录删除了此文件因此执行 restore temp2.txt 命令后后显示 deleted temp2.txt 未加入暂存区。 3.3.3 撤销暂存以及工作区修改git checkout 可以实现一样的功能git reset --hard HEAD 能恢复到某个历史提交但不能针对单个文件恢复其内容git restore --staged --worktree pathspec… 回到最近一次提交状态 3.3.4 使用 git reset 撤销工作区修改或撤销暂存
参考 3.7 3.8
3.3.5 使用 git checkout 恢复某个文件
git checkout commit file 命令会将某个文件恢复到指定提交的状态且会丢失未提交的修改。 3.4 删除文件 git rm
3.4.1 删除文件 git rm pathspec…
使用 git rm 命令从已跟踪文件清单中移除文件确切地说是从暂存区域移除并连带从工作目录中删除指定的文件执行 git rm 后再执行 git commit即可从 Git 中移除文件。
如果只是简单地从工作目录中手工删除文件运行 git status 时就会在 “Changes not staged for commit” 部分也就是未暂存清单看到deleted: filename运行 git rm 记录此次移除文件的操作下一次执行 git commit 后该文件就不再纳入版本管理了。
3.4.2 强制删除文件 git rm -f pathspec…
如果文件没有被添加到 Git 仓库中git rm 命令会报错如果你尝试删除一个修改过并且已经把修改放到暂存区的文件git rm 命令会提示你需要先将修改提交到 Git 仓库中。 如果一定要删除之前修改过并且已经放到暂存区的文件或者仓库中不存在的文件要用强制删除选项 -fforce 的首字母。git rm -f 命令可以强制删除已经被 Git 跟踪的文件即使该文件被修改过并且没有被提交到 Git 仓库中使用该命令时需要小心它会永久删除文件无法恢复。 3.4.3 从暂存区和 Git 仓库中删除但本地不删除 git rm -cached pathspec…
当想把文件从 Git 仓库中删除亦从暂存区域移除但仍然希望保留在当前工作目录中时使用 git rm --cached pathspec… 。 换句话说你想让文件保留在磁盘但是并不想让 Git 继续跟踪。 $ git rm log/\*.log
# 表示删除 log/ 目录下扩展名为 .log 的所有文件
# 星号 * 之前的反斜杠 \这是 Git 自己的文件模式扩展匹配方式。$ git rm \*~、
# 表示删除以 ~ 结尾的所有文件。
3.5 移动文件 git mv source destination $ git mv README.md README 命令 git mv README.md README将对文件改名运行此命令相当于运行了下面三条命令
$ mv README.md README
$ git rm README.md
$ git add README 3.6 比较文件内容 git diff 比较工作目录中的文件与最新提交之间的差异git diff 比较指定文件在工作目录和最新提交之间的差异git diff file 比较工作目录中的文件与指定的提交之间的差异git diff commit 比较两个提交之间的差异git diff commit1 commit2 比较指定文件在两个提交之间的差异git diff commit1 commit2 file 比较两个分支之间的差异git diff branch1 branch2 比较指定文件在两个分支之间的差异git diff branch1 branch2 file 3.7 提交更新 git commit
3.7.1 提交更新-编辑器输入提交信息 git commit
如果暂存区域已经准备妥当可以提交了就可以使用 git commit 命令将修改提交到仓库。 请一定要确认还有什么修改过的或新建的文件还没有 git add 过否则提交的时候不会记录这些还没暂存起来的变化这些修改过的文件只保留在本地磁盘。 所以每次准备提交前先用 git status 看下是不是都已暂存起来了 然后再运行提交命令 git commit。
这种方式将会启动文本编辑器以便输入本次提交的说明。 (默认会启用 shell 的环境变量 EDITOR 所指定的软件 一般都是 vim 或 emacs。编辑器显示的内容示例 第一行是空行供你输入提交说明。提交消息的注释行里包含最后一次运行 git status 的输出其实完全可以去掉这些注释行不过留着也没关系多少能帮你回想起这次更新的内容有哪些。 如果想要更详细的关于修改了哪些内容的提示可以用 -v 选项这会将你所做的改变的 diff 输出放到编辑器中使你知道本次提交具体做了哪些修改。退出编辑器时Git 会丢掉注释行用你输入提交附带信息生成一次提交。
注Vim 使用
正常模式 :- 命令模式内置命令如 w wq
正常模式 i- 插入模式编辑功能Esc- 正常模式
先在键盘点击 i 按键进入插入模式然后在首行填写提交描述完成后点击 Esc 退出插入模式接下来按 : 进入命令模式输入 wq 保存并退出。 3.7.2 提交更新-直接输入提交信息 git commit -m msg
可以在 commit 命令后添加 -m 选项将提交信息与命令放在同一行这样就不必通过 vim 添加提交信息了。 如果你只需要提交一些小的更改并且提交信息比较简单可以使用 git commit -m 命令如果你需要提交一些比较大的更改并且需要详细描述这些更改的内容那么可以使用 git commit 命令并在编辑器中输入详细的提交信息。
3.7.3 重新提交 git commit --amend -m msg
如果在提交完才发现漏掉了几个文件没有添加或者提交信息写错了可以运行带有 --amend 选项的提交命令尝试重新提交最终将只有一个提交。 修补提交最明显的价值是可以稍微改进你最后的提交而不会让 “啊忘了添加一个文件”或者 “小修补修正笔误” 这种提交信息弄乱你的仓库历史。 例如你提交后发现忘记了暂存某些需要的修改可以像下面这样操作
$ git commit -m initial commit
$ git add forgotten_file
$ git commit --amend -m initial commit with supplements
文本编辑器启动后可以看到之前的提交信息 编辑后保存会覆盖原来的提交信息。 3.7.4 撤销提交 git reset [--soft/mixed/hard] [commit]
参考 3.7、3.8
3.7.5 为提交打标签 git tag
标签可以用来标识特定的提交或版本方便用户在未来快速找到这个提交或版本。Git 主要有两种类型的标签轻量标签lightweight与附注标签annotated。
轻量级标签只是一个指向特定提交的引用它不包含任何其他元数据因此比带注释的标签annotated tag更轻量级通常用于临时标记某个特定的提交。附注标签是存储在 Git 数据库中的一个完整对象是可以被校验的其中包含打标签者的名字、电子邮件地址、日期时间以及标签信息。 通常建议创建附注标签这样你可以拥有以上所有信息但如果你只是想用一个临时的标签或者因为某些原因不想保存那些信息用轻量标签也是可以的。
查看标签和删除标签
使用 git tag 查看标签这个命令以字母顺序列出标签注意标签不是按时间顺序列出而是按字母排序的使用 git show tagname 查看指定标签的详细信息包括标签的提交信息和提交内容使用 git tag -d tagname 删除指定的标签。
创建标签
在 Git 中创建标签非常简单切换到需要打标签的分支上然后运行 git tag 命令即可。默认标签是打在最新提交的 commit 上的。 创建轻量标签时只需要提供标签名字如git tag v1.4-lw。创建附注标签需要在运行 tag 命令时指定 -a 选项如git tag -a v1.4 -m my version 1.4-a 选项表示创建一个附注标签-m 选项指定了一条将会存储在标签中的信息如果没有为附注标签指定一条信息Git 会运行编辑器要求你输入信息。 后期打标签
如果想对过去的提交打标签可以先运行 git reflog 查看历史提交信息找到目标提交的校验和或部分校验和在命令末尾加上它如git tag -a v1.2 9fceb02。
共享标签
默认情况下git push 命令并不会传送标签到远程仓库服务器上。 在创建完标签后你必须显式地推送标签到共享服务器上。 这个过程就像共享远程分支一样运行 git push origin [tagname]。如果标签已经推送到远程要删除远程标签就麻烦一点比如想删除 remove 标签需要先从本地删除git tag -d remove然后从远程删除删除命令也是 push但是格式如下git push origin :refs/tags/remove。
3.8 查看提交历史 git log
3.8.1 git log
默认不用任何参数的话git log 会按提交时间列出所有的更新最近的更新排在最上面。 这个命令会列出每个提交的哈希值、作者的名字和电子邮件地址、提交时间以及提交说明。 3.8.2 git log --oneline
--oneline将每个提交压缩为一行是 --prettyoneline --abbrev-commit 的简写形式。 3.8.3 其他常用选项-p、-n、--stat、--pretty、--graph
-p 选项用来显示每次提交的内容差异。
-(n) 仅显示最近的 n 条提交。 --stat 选项查看每次提交的简略的统计信息。--stat 选项在每次提交的下面列出所有被修改过的文件、有多少文件被修改了以及被修改过 的文件的哪些行被移除或是添加了。 在每次提交的最后有一个总结。 --pretty指定使用不同于默认格式的方式展示提交历史。
--pretty 选项有 一些内建的子选项可供使用比如 oneline 表示将每个提交放在一行显示格式为 hash title-lineformat:format-string 定制要显示的记录格式如 %h 代表提交的简短哈希值%s 代表提交说明消息%an 代表作者名字%cn 代表提交者名字%cd 代表提交日期等还有 short、medium、full、fuller 等内置格式。 如果要将输出保存到文件中可以使用以下命令git log --prettyformat:%H - %an: %s log.txt
-S仅显示添加或移除了某个关键字的提交。
可以使用命令git log -Sfunction_name找出添加或移除了某一个特定函数的引用的提交。
3.8.4 git reflog
git log 显示的是提交历史包括每个提交的作者、提交时间、提交信息等等。它可以用于查看项目的提交历史了解项目的演进情况以及查找特定提交的信息等等。
Git 会在后台保存一个引用日志 reflog每当你的 HEAD 所指向的位置发生了变化Git 就会将这个信息存储到引用日志这个历史记录里。 通过这些数据你可以很方便地获取之前的提交历史使用 git reflog 来查看引用日志。
git reflog 显示的是 Git 引用的历史包括分支、标签、HEAD 等等。它记录了 Git 引用的变更历史可以用于恢复误删的分支、标签等引用或者查找误操作的历史记录等等。 3.9 撤销提交 git reset
git reset 可用于 取消暂存不影响工作区内容对应下图 SYNOPSIS 1~3 语句。取消提交将当前分支的 HEAD 指针移动到指定的提交同时可以选择是否修改工作区和暂存区的内容。对应下图 SYNOOSIS 第4条语句。 3.9.1 保留工作区修改撤销暂存tree-ish 默认为 HEAD即最近一次的提交
应用场景假设你对项目中的 frotz.c 文件做了一些修改已经改好了接下来需要修改其他文件你不想在运行 git diff 时看到关于 frotz.c 的内容这会分散你的注意力所以你使用 add 命令把这部分修改暂存到暂存区。
这时有人告诉你其他项目成员做了一些有价值的修改建议你拉取最新项目。不过你现在已经 ‘弄脏了’ 暂存区即你当前的暂存区内容与 HEAD 不匹配执行 git pull 之前需要先将暂存区和 HEAD 同步否则会出现冲突而且你知道将要进行的 pull 操作不会改变 frotz.c 文件因此你可以考虑先恢复 frotz.c 文件在暂存区的状态撤销之前的暂存操作但保留工作区文件的改动然后再pull、merge。 git reset 也可以仅对一个文件撤销暂存操作 3.9.2 撤销提交commit 默认为 HEAD即最近一次的提交
-soft仅撤销提交不撤销修改。将 HEAD 指针移动到指定的提交并将暂存区和工作区的修改保留下来因此可以直接重新提交。--mixed撤销提交和暂存区的修改但不撤销工作区的修改。将 HEAD 指针移动到指定的提交并将暂存区的修改撤销但不影响工作区的修改需要手动重新标记为暂存后再次提交。--hard彻底撤销提交和修改回到指定提交的状态。将 HEAD 指针、暂存区和工作区都移动到指定的提交所有修改都会被撤销慎用。--merge撤销合并提交回到合并前的状态。撤销合并提交回到合并前的状态需要指定要回到的提交。--keep撤销提交但保留工作区和暂存区的修改。
可以通过回退实现撤销提交这需要知道回到哪个版本用 HEAD 表示当前版本即最新的提交上一个版本用 HEAD^ 表示往上100个版本用 HEAD~100 表示此外如前所述 Git 会记录每一次提交的信息可通过 git reflog 查看索引值用索引值指定要回退的版本。概括来说 索引值前进后退都可以使用 HEAD 或局部索引值提交对象的简短哈希字符串可通过 git reflog 或 git log --prettyoneline 查看如git reset --hard 49e25b6 ^ 只能后退HEAD^^ 表示后退 2 步如git reset --hard HEAD^^~ 只能后退HEAD~n 表示后退 n 步如git reset --hard HEAD~n --hard 永久删除本地内容也会删除 3.9.3 git restore 与 git reset
git restore撤销工作区中未提交的修改从暂存区或另一个提交恢复工作区中的文件从另一次提交中恢复暂存区或\和工作区中的文件。
git reset撤销已提交的修改。将 HEAD 指针和当前分支指向指定的提交可选择将暂存区或\和工作区恢复到该提交的状态。 4. 分支管理
使用分支意味着你可以把你的工作从开发主线上分离开来以免影响开发主线。
Git 处理分支的方式可谓是难以置信的轻量创建新分支这一操作几乎能在瞬间完成并且在不同分支之间的切换操作也是一样便捷。 与许多其它版本控制系统不同Git 鼓励在工作流程中频繁地使用分支与合并哪怕一天之内进行许多次。
4.1 分支简介
4.1.1 文件快照
Git 并不是像其他版本控制系统一样把保存的信息看作是一组基本文件和每个文件随时间逐步累积的差异Git 更像是把数据看作是对小型文件系统的一组快照你可以理解为每个快照都包含了代码库中的所有文件和目录的完整内容。Git 对待数据更像是一个快照流使用这些快照来跟踪文件的历史记录并允许不同版本之间进行比较和回滚。
说明Git 的快照是通过将文件的内容转换为一些称为 “blob” 的二进制数据对象来实现的。Git 中的每个文件都被视为一系列 blob 对象每个 blob 对象都包含文件的内容当你在 Git 中提交一个更改时Git 会将这些更改的内容转换为新的 blob 对象并将其存储在 Git 数据库中。Git 还会创建一个称为 “tree” 的对象该对象包含指向每个 blob 对象的指针以及目录结构信息。 这些 blob 和 tree 对象都可以被视为 Git 中的 “快照”因为它们表示特定时间点的文件和目录结构。
在你每次提交更新或在 Git 中保存项目状态时Git 会对当时的全部文件制作一个快照并保存这个快照的索引。 为了高效 如果文件没有修改Git 不再重新存储该文件而是只保留一个链接指向之前存储的文件。 Git 中的绝大多数操作都只需要访问本地文件和资源比如如果 Git 要浏览项目的历史它不需外连到服务器去获取历史然后再显示出来只需直接从本地数据 库中读取因此你能立即看到项目历史。
4.1.2 验证文件 哈希是一种算法它将输入的数据映射到一个固定长度的输出通常是一个哈希值。在计算机科学中哈希经常用于快速查找和存储数据。密码学中哈希算法可以把明文加密成密文。 哈希函数如下特点 1同一个哈希算法得到的加密结果长度固定。 2哈希算法确定、输入数据确定输出数据不变如果哈希算法有变化或者输入数据变化即便是很微小的变化输出数据一定有变化而且变化很大。输入数据的任何细微变化都会导致输出数据的巨大变化。 3哈希算法不可逆不能通过哈希值恢复出原始数据。 哈希算法可以用于验证文件Git 中每个文件和每个提交都有一个唯一的校验和是一个 SHA-1 哈希值一个由 40 个十六进制字符0-9 和 a-f组成字符串示例24b9da6552252987aa493b52f8696cd6d3b00373这个校验和是由文件内容和目录结构计算出来的可以用来验证文件的完整性和一致性。Git 数据库中保存的信息都是以文件内容的哈希值来索引而不是文件名。
4.1.3 Git 分支管理机制 提交对象 commit包含指向前述树对象的指针和所有提交信息。 树对象 tree树对象包含了每个文件和子目录的名称、类型、权限和 SHA-1 校验和等元数据信息。当我们提交一个新版本的代码时Git 会将所有修改的文件和目录打包成一个新的树对象并将其保存到 Git 数据库中。 文件快照 blob 对象当前版本的文件快照。 在 Git 中每次提交都会生成一个校验和这个校验和是由 Git 对该提交中所有文件的内容计算出来的。如果你修改了某些文件并提交了这些修改Git 会重新计算该提交的校验和并将其与之前的校验和进行比较。如果校验和不同Git 就会认为文件已经被修改过了并提示你进行提交。 当你做了一些修改后再次提交这次产生的提交对象会包含一个指向上次提交对象父对象的指针。 Git 的分支本质上是指向提交对象的可变指针。 Git 的默认分支名字是 master。 在多次提交操作之 后你其实已经有一个指向最后那个提交对象的 master 分支它会在每次的提交操作中自动向前移动。
Git 的 master 分支并不是一个特殊分支。 它就跟其它分支完全没有区别。 之所以几乎每一个仓库都有 master 分支是因为 git init 命令默认创建它并且大多数人都懒得去改动它。
Git 怎么知道当前在哪一个分支上呢 也很简单它有一个名为 HEAD 的特殊指针。 在 Git 中HEAD 是一个指针指向当前所在的本地分支注可以将 HEAD 想象为当前分支的别名。 首次提交产生的提交对象没有父对象普通提交操作产生的提交对象有一个父对象由多个分支合并产生的提交对象有多个父对象。
4.2 分支的查看、创建、切换、删除
4.2.1 查看分支 git branch 选项 -v、-r、-a、--merged、--no-merged
果不加任何参数运行 git branch会得到当前所有分支的一个列表* 字符代表当前所处的那一个分支当前 HEAD 指针所指向的分支。 If --list is given, or if there are no non-option arguments, existing branches are listed; the current branch will be highlighted in green and marked with an asterisk. 使用 git branch -v 显示本地分支列表并显示每个分支的最新提交的 SHA-1 值和提交信息。 git branch -r 显示远程跟踪分支列表。
git branch -a 显示所有分支列表包括本地分支和远程跟踪分支。 使用 git branch --merged 查看哪些分支已经合并到当前分支。在这个列表中分支名字前没有 * 号的分支通常可 以使用 git branch -d 删除掉你已经将它们的工作整合到了另一个分支所以并不会失去任何东西。
使用 git branch --unmerged 查看所有包含未合并工作的分支。因为这个列表中的分支包含了还未合并的工作尝试使用 git branch -d 命令删除这些分支时会失败。
下面的例子中没有所有分支都已合入到 master 分支。 4.2.2 创建分支 git branch branchname
Git 中创建分支即为创建一个可以移动的新的指针。比如创建一个 testing 分支 只需要使用 git branch 命令git branch testing这会在当前所在的提交对象上创建一个指针。git branch 命令仅仅创建一个新分支并不会自动切换到新分支中去因此当前你仍然在 master 分支上。 4.2.3 切换分支 git checkout 和 git switch
1git checkout
使用 git checkout 命令要切换到一个已存在的分支比如现在要切换到新创建的 testing 分支 去 git checkout testing这样 HEAD 就指向 testing 分支了。 如果现在对项目中某文件做些修改然后再提交一次testing 分支将会向前移动但 master 分支不动仍然指向运行 git checkout 时所指的对象。 使用命令 git checkout master切换回 master 分支。这条命令做了两件事1使 HEAD 指回 master 分支2是将工作目录恢复成 master 分支所指向的快照内容。也就是说如果现在做修改是始于一个较旧的版本本质上来讲这就是忽略 testing 分支所做的修改便于向另一个方向进行开发。 分支切换会改变你工作目录中的文件。在切换分支时一定要注意你工作目录里的文件会被改变。 如果是切换到一个较旧的分支工作目录会恢复到该分支最后一次提交时的样子。 如果 Git 不能干净利落地完成这个任务 它将禁止切换分支。
你可以简单地使用 git log 命令查看分叉历史。 运行 git log --oneline --decorate --graph --all它会输出你的提交历史、各个分支的指向以及项目的分支分叉情况。
2git switch The command git branch branchname will create the new branch, but it will not switch the working tree to it; use git switch newbranch to switch to the new branch. 在 Git 2.23 版本之前git checkout 用于切换分支、恢复文件、创建新分支等多种操作的命令。但是从 Git 2.23 版本开始它被拆分成了多个命令以避免使用时的混淆。现在git checkout 命令主要用于切换分支和恢复文件。例如git checkout master 将当前分支切换到 master 分支git checkout -- file.txt 将 file.txt 文件恢复到最近一次提交的状态。
从 Git 2.23 版本开始git switch 命令被引入用于切换分支。它的使用方式与 git checkout 类似但是更加直观和简洁。例如git switch master 将当前分支切换到 master 分支。
如果你使用的是 Git 2.23 及以上版本建议使用 git switch 命令来切换分支以避免混淆。如果你使用的是较老的 Git 版本可以继续使用 git checkout 命令但需要注意其多种用法可能会导致一些意外情况。
4.2.4 创建并切换到此分支 git checkout -b branchname
git checkout -b 命令用于创建一个新的分支并切换到该分支-b 参数表示创建一个新的分支。比如带有 -b 参数的 git checkout 命令git checkout -b iss53实际上是下面两条命令的简写
$ git branch iss53
$ git checkout iss53
执行该命令后Git 会将当前分支的代码复制到新的分支中并将 HEAD 指向新的分支你可以在新的分支上继续开发代码而不影响当前分支的代码。
4.2.5 删除分支 git branch -d branchname 删除未合并的分支需要使用 git branch -D删除已合并的分支需要使用 git branch -d。
4.3 分支的合并 git merge、git cherry-pick 使用 git merge 合并分支先 check out 到想合并入的分支然后执行 git merge。 Case 1把 hotfix 分支合并入 master 分支
假设在当前项目中先从 master 分支创建了一个 hotfix 分支并在在 hotfix 分支提交了一些修改现在想把 hotfix 分支修改的内容合并到 master。 提交历史checkout 到 master然后执行 git merge 你应该注意到了运行结果中的 快进fast-forward这个词。 由于当前 master 分支所指向的提交是 hotfix 分支的提交的直接上游所以 Git 只是简单的将指针向前移动。 即当你试图合并两个分支时如果顺着一个分支走下去能够到达另一个分支那么 Git 在合并两者的时候只会简单的将指针向前推 进指针右移因为这种情况下的合并操作没有需要解决的分歧——这就叫做 “快进fast-forward”。
Case 2把 iss53 分支合并入 master 分支
hotfix 分支上所做的工作并没有包含到 iss53 分支中如果需要拉取 hotfix 所做的修改可以使用 git merge master 命令将 master 分支合并入 iss53 分支或者你也可以等到 iss53 分支完成其使命 再将其合并回 master 分支。
在 Case 1 中master 已经合入了 hotfix 分支的内容快照流图示如下 如果在 iss53 分支上的工作完成了可以考虑将其合并入 master 分支 。合并 iss53 分支到 master 分支与之前合并 hotfix 分支所做的工作差不多只需要 checkout 到你想合并入的分支然后运行 git merge 命令。 可以注意到返回结果与之前合并 hotfix 分支的时候看起来有一点不一样这是因为iss53 分支是从更早的地方分叉开的divergedmaster 分支已经前进master 所在提交已经不是 iss53 分支所在提交的直接祖先。 出现这种情况的时候Git 会使用两个分支的末端所指的快照C4 和 C5 以及这两个分支的工作祖先C2做一个简单的三方合并。 Case 3存在冲突
如果在两个不同的分支中对同一个文件的同一个部分进行了不同的修改Git 就没法干净的合并它们。 比如在上述例子中如果 iss53 和 hotfix 两个分支对同一个文件的同一处做了修改合并它们的时候就会产生合并冲突。
看一个简单的例子项目的提交历史如下
# 在 master 分支新建一个 file1.txt 文件
$ git add file1.txt
$ git commit -m master create file1.txt# 新建 file2 分支在这个分支上新建了 file2.txt 文件同时对 file1.txt 追加了一行内容
$ git checkout -b file2
$ git add file2.txt
$ git commit -a -m create file2 and file1 add a line# 回到 master分支对 file1.txt 文件追加一行内容
$ git checkout master
$ git commit -a -m file1 add a line# 把 file2 分支的修改内容并入到 master 分支
$ git branch -v
$ git merge file2
在当前的项目中有 master 和 file2 两个分支都在 file2.txt 的末尾追加了一段文字现在想合并这两个分支先 checkout 到 master然后运行 git merge poem-1 命令。 由于两个分支在相同的位置做了修改存在冲突合并时不知道采用哪一个合并失败 任何因存在合并冲突而有待解决的文件都会以未合并状态标识出来你可以在合并冲突后的任意时刻使用 git status 命令查看那些因存在合并冲突而处于未合并 unmerged状态的文件。Git 会在有冲突的文件中加入标准的冲突解决标记这样你可以打开这些包含冲突的文件然后手动解决冲突。 当前的例子中两个分支都对 file2.txt 文件做了修改打开这个文件显示内容如下 Git 用 标记出不同分支的内容上述信息表示HEAD 指示的版本在 的上半部分而 poem-1 指示的版本在 的下半部分。
为了解决冲突你可以选择使用由 分割的两部分中的一个或者自行合并这些内容。根据实际需要确定冲突解决方案完成修改后把 和 这些行完全删除。 在解决了所有文件里的冲突之后对每个文件使用 git add 命令来将其标记为冲突已解决。 一旦暂存这些原本有冲突的文件Git 就会将它们标记为冲突已解决然后再执行 commit 提交即可。 Case 4储藏现场 git stash
git stash 命令可以将当前工作目录中未提交的修改 “储藏” 起来具体使用方法如下 在工作目录中进行一些修改运行 git stash 命令将修改储藏起来在进行其他操作之前可以运行 git stash list 命令查看所有储藏使用 git stash apply 命令恢复储藏内容使用 git stash drop 命令删除储藏。 假设你当前有 master 和 dev 两个分支你临时接到紧急任务准备新建一个 issue-101 分支修复一个 bug但是你在 dev 上进行的工作还没有做完还不能提交这时你可以用 git stash把当前的工作现场储藏起来等以后恢复现场继续工作。
运行过程
# 保存现场
$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
# 现在用 git status查看工作区是干净的除非有没有被Git管理的文件# 接下来创建分支修复 bug
$ git checkout master
$ git checkout -b issue-101
$ git commit -m fix bug 101
$ git switch master
$ git merge --no-ff -m merged bug fix 101 issue-101# 恢复现场
$ git switch dev
$ git stash list
stash{0}: WIP on dev: f52c633 add merge
# 工作现场还在Git 把 stash 内容存在某个地方了需要恢复
# 方法1用 git stash apply 恢复恢复后 stash 内容并不删除需要用 git stash drop 删除
# 方法2用 git stash pop恢复的同时把 stash 内容删除。$ git stash pop
$ git stash list
# 此时将看不到任何 stash 内容
Case 5挑选提交合并 git cherry-pick commitHash
git merge 可以将两个或多个分支合并成一个新的分支它会将两个分支的修改内容合并到一起并生成一个新的提交记录。git merge 会自动解决冲突但有时会出现无法自动解决的冲突需要手动解决。
如果你想将一个分支上的某个或某几个提交记录复制到当前分支上比如要解决某个 bug 或者应用某个特定的功能可以使用 git cherry-pick。
git cherry-pick 可以选择性地将某个提交记录合并到当前分支而不会像 git merge 一样将整个分支合并。git cherry-pick 将一个或多个提交应用到当前分支。它的作用是将指定的提交复制一份到当前分支上相当于手动合并某个提交。
更多细节参考链接Git 操作补充cherry-pick、变基-CSDN博客
Case 6变基 git rebase
在 Git 中整合来自不同分支的修改除了 merge还有一种方法变基 rebase。它可以将一个分支上的修改合并到另一个分支上。具体来说Git 变基的操作是将当前分支的提交 “复制” 到目标分支上然后将当前分支的指针指向目标分支的最新提交。这个过程中Git 会尝试将当前分支上的提交应用到目标分支上如果发现冲突需要手动解决冲突。
与 Git 合并 merge 不同Git 变基可以重新定义提交历史使得提交历史更加整洁和易于理解。Git 变基的优点是可以保持提交历史的清晰减少不必要的合并提交从而更好地追踪代码的变化。不过由于 Git 变基会修改提交历史因此需要谨慎使用避免对已经共享的分支造成影响。
更多细节参考链接Git 操作补充cherry-pick、变基-CSDN博客
4.5 分支开发工作流
* 长期分支
Git 使用简单的三方合并所以就算在一段较长的时间内反复把一个分支合并入另一个分支也不是什么难事。 也就是说在项目开发周期内你可以同时拥有多个开放的分支定期地把某分支合并入其他分支中。
使用多个长期分支的方法并非必要但是这么做通常很有帮助尤其是当你在一 个非常庞大或者复杂的项目中工作时这样做可以使你的分支具有不同级别的稳定性当其具有一定程度的稳定性后再把它合并入具有更高级别稳定性的分支中。
例子只在 master 分支上保留完全稳定的代码——有可能仅仅是已经发布或即将发布的代码。 他们还有一些名为 develop 或者 next 的平行分支被用来做后续开发或者测试稳定性——这些分支不必保持绝对稳定但是一旦达到稳定状态它们就可以被合并入 master 分支了。 * 特性分支短期分支
特性分支对任何规模的项目都适用。 特性分支是一种短期分支它被用来实现单一特性或其相关工作。
例子在 master 分支上工作到 C1这时为了解决一个问题 A 而新建 iss91 分支在 iss91 分 支上工作到 C4然而对于问题 A 你又有了新的想法于是你再新建一个 iss91v2 分支试图用另一种方法解决它接着你回到 master 分支工作了一会儿你又冒出了一个不太确定的想法想为项目增加了新功能便在 C10 的时候新建一个 dumbidea 分支并在上面做些实验。你的提交历史看起来像下面这个样子 你最终决定使用在 iss91v2 分支中方案解决问题 A同时你将 dumbidea 分支拿给你的同事看大家都觉得这部分内容值得保留这时你可以抛弃 iss91 分支丢弃 C5 和 C6 提交然后把另外两个分支合并入主干分支。最终你的提交历史看起来像下面这个样子 5. 远程仓库 remote repository
5.1 相关概念
5.1.1 远程仓库 remote repository Git 的远程仓库是指位于网络上的 Git 仓库托管在因特网或其他网络中的项目版本库。 它可以是位于本地局域网内的另一台计算机也可以是位于云端的服务器。Git 的远程仓库可以让多个开发者在不同的地方协同开发同一个项目通过上传和下载代码来实现代码的共享和同步。
你可以有好几个远程仓库通常有些仓库对你只读有些则可以读写。 与他人协作涉及管理远程仓库以及根据需要推送push或拉取fetch数据。
5.1.2 远程分支 remote branch
远程分支即远程仓库上的分支要在 Git 中创建远程分支需要使用 git push 命令。以下是创建远程分支的步骤如下 在本地创建一个新的分支可以使用 git checkout -b 命令创建并切换到新分支。在本地分支上进行了所需的更改。使用 git push 命令将本地分支推送到远程仓库。例如远程仓库名为 origin可以使用以下命令将本地分支 mybranch 推送到远程分支git push origin mybranch如果远程仓库不存在此分支Git 会自动创建它。使用 git branch -r 命令查看远程分支列表新远程分支应该出现在列表中。 注意: 在推送分支之前需要确保你有足够的权限在远程仓库中创建分支如果没有权限需要联系仓库管理员以获取帮助。
git push 的语法规则可概括为git push 远程仓库名 本地分支名:远程分支名
如果你的本地分支与远程分支同名则可以省略远程分支名。可以使用带冒号 “:” 的格式来推送本地分支到一个命名不相同的远程分支比如不想让远程仓库上的分支叫做 serverfix可以运行 git push origin serverfix:awesomebranch将本地的 serverfix 分支推送到远程仓库上的 awesomebranch分支。
可以运行带有 --delete 选项的 git push 命令来删除一个远程分支比如想要从服务器上删除 serverfix 分支运行命令git push origin --delete serverfix
5.1.3 远程跟踪分支 remote-tracking branch 执行 clone 后远程仓库的分支会被克隆到本地但是本地仓库中的分支与远程仓库中的分支的发展不是完全同步的。为了跟踪远程仓库中的分支Git 会在本地仓库中创建一个名为 remotes/remote-name/branch-name 的分支这个分支就是 remote-tracking branch。 remote branch 是指远程仓库上的分支。 remote-tracking branch 远程跟踪分支是远程分支状态的引用。它们是你不能移动的本地引用当你做任何网络通信操作时它们会自动移动。 远程跟踪分支像是你上次连接到远程仓库时那些分支所处状态的书签。它们以 (remote)/(branch) 形式命名。 比如如果你想要看你最后一次与远程仓库 origin 通信时 master 分支的状态你可以查看 origin/master 分支。 可以通过 git branch -r 命令来查看所有远程仓库的分支通过 git branch -a 命令来查看所有本地分支和远程分支。 clone 远程仓库使用 clone 命令克隆了一个仓库命令会自动将其添加为远程仓库并默认以 origin 为简写。即 Git 的 clone 命令会自动将这个远程仓库命名为 origin拉取它的所有数据创建一个指向此远程仓库 master 分支的指针并且在本地将其命名为 origin/master远程跟踪分支Git 也会给你一个与 origin 的 master 分支在指向同一个地方的本地 master 分支跟踪分支这样你就有工作的基础。
远程仓库的名字 origin 与分支名字 master 一样在 Git 中并没有任何特别的含义。 master 是运行 git init 时默认的起始分支名字 origin 是运行 git clone 时默认的远程仓库名字。 如果运行 git clone -o booyah那么默认的远程分支名字将会是 booyah/master。 如果你在本地的 master 分支做了一些工作然而在同一时间其他人推送提交到远程仓库更新了它的 master 分支那么你的提交历史将向不同的方向前进但只要你不与 origin 服务器连接你的 origin/master 指针就不会移动。 5.1.4 跟踪分支
从一个远程跟踪分支检出一个本地分支会自动创建一个 “跟踪分支”有时候也叫做 “上游分支”。 跟踪分支是与远程分支有直接关系的本地分支。 如果在一个跟踪分支上输入 git pullGit 能自动地识别去哪个服务器上抓取、合并到哪个分支。 当克隆一个仓库时它通常会自动地创建一个跟踪 origin/master 的 master 分支。
如果需要的话可以通过运行 git checkout -b [branch] [remotename]/[branch] 设置其他跟踪分支、跟踪此仓库的其他分支或者为其他仓库设置跟踪分支这是一个十分常用的操作所以 Git 提供了 --track 快捷方式。 $ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch serverfix 此命令将创建一个用于工作的本地分支 serverfix并且起点位于 origin/serverfix。 $ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch serverfix 本地分支与远程分支设置为不同名字本地分支 sf 会自动从 origin/serverfix 拉取 $ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch sf 可以使用带有 -u 或 --set-upstream-to 选项的 git branch 显式地设置已有的本地分支跟踪一个刚刚拉取下来的远程分支或者修改正在跟踪的上游分支。 $ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. 总结Git 跟踪分支是指本地仓库中的分支是基于本地仓库中的提交记录创建的可以在本地进行修改、合并等操作。远程跟踪分支是指远程仓库中的分支它们是基于远程仓库中的提交记录创建的不能直接在本地进行修改、合并等操作需要通过拉取或推送远程分支来进行操作。 5.2 查看远程仓库 git remote -v
git remote 显示当前仓库所关联的远程仓库。git remote -v 显示详细的远程仓库信息包括远程仓库的名称、fetch 和 push 的URL地址。git remote show remote-name 查看某一个远程仓库的更多信息。 5.3 添加新的远程仓库 git remote add shortname url
可以使用 git remote add shortname url 命令添加一个新的远程 Git 仓库并为其指定一个方便引用的简称。 可以使用 git remote rename 修改远程仓库的简写名即远程仓库重命名比如想要将 pb 重命名为 paul可以运行git remote rename pb paul值得注意的是这同样也会修改你的远程分支名字过去那些引用 pb/master 的现在会引用 paul/master。
可以使用 git remote rm 移除远程仓库如git remote rm paul
5.4 从远程仓库拉取 git fetch remote-name 和 git pull remote-name
5.4.1 git fetch 如果要同步你的工作运行 git fetch origin 命令。 这个命令查找 origin 这个名字对应哪一个服务器从中抓取本地没有的数据并且更新本地数据库移动 origin/master 指针指向新的、更新后的位置。 $ git remote
origin$ git remote add pb https://github.com/paulboone/ticgit$ git remote -v
origin https://github.com/schacon/ticgit (fetch)
origin https://github.com/schacon/ticgit (push)
pb https://github.com/paulboone/ticgit (fetch)
pb https://github.com/paulboone/ticgit (push)$ git fetch pb
remote: Counting objects: 43, done.
remote: Compressing objects: 100% (36/36), done.
remote: Total 43 (delta 10), reused 31 (delta 5)
Unpacking objects: 100% (43/43), done.
From https://github.com/paulboone/ticgit
* [new branch] master - pb/master
* [new branch] ticgit - pb/ticgit
5.4.2 git pull 当 git fetch 命令从服务器上抓取本地没有的数据时git fetch 会将远程仓库的最新代码下载到本地但它并不会修改工作目录中的内容它只会获取数据然后让你自己合并想要更新本地分支你需要手动执行 git merge 或者 git rebase 命令来合并最新代码。
通常来讲git pull 的含义是一个 git fetch 紧接着一个 git merge 命令。 如果有一个设置好的跟踪分支不管它是显式设置的还是通过 clone 或 checkout 命令创建的git pull 会查找当前分支所跟踪的服务器与分支从服务器上抓取数据然后尝试合并入那个远程分支。
总的来说git fetch 更加安全因为它不会自动合并代码你可以在合适的时候手动合并而 git pull 更加方便因为它可以自动合并代码让你更快地获取最新的代码。
5.5 本地分支推送到远程仓库 git push 推送分支就是把该分支上的所有本地提交推送到远程库。建议在 git push 之前先执行 git pull 命令以确保本地代码库与远程代码库同步。
如果远程代码库中已经存在一些新的提交而你本地的代码库没有进行更新那么你的 push 操作会被拒绝因为你的本地代码库与远程代码库不一致。
推送时要指定本地分支比如运行 git push origin masterGit 会把 master 分支推送到远程库对应的远程分支上。如果要推送其他分支比如 dev就用git push origin dev。 多人协作小结 首先可以试图用 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。
6. 问题记录
6.1 添加 remote 信息时报错unable to get local isser certificate服务器上SSL证书未经过第三方机构认证
git config --global http.sslverify false
6.2 git pull fatal: refusing to merge unrelaterd histories
git pull origin master --allow-unrelated-histories
6.3 Pycharm 侧边栏没有 Commit
Settings - Version Control - Commit - 勾选 use non-modal commit interface - Apply 7. 参考链接
Git安装-Git入门-CSDNGit技能树
Pro GitGit - Book
