Git入门书籍 Pro Git 书籍系列 24

git push -f命令的用法git push -f 是 Git 中的一个重要命令，用于将本地的提交强制推送到远程仓库。

通常在以下情况下使用该命令：1. 同步远程仓库：当本地和远程仓库的提交历史不一致时，使用 git push -f 可以强制将本地的提交历史覆盖远程仓库的提交历史，使两者一致。

2. 修改历史提交：当需要修改已经提交的历史记录时，可以通过 git push -f 强制覆盖远程仓库的提交历史，将修改后的提交历史推送上去。

3. 撤销错误提交：当不小心提交了错误的代码或文件时，通过git push -f 可以将本地的修复提交覆盖远程仓库，这样其他开发人员获取新代码时就不会看到错误的提交。

下面是一些相关参考内容，对 git push -f 命令的使用进行了介绍和解释：1. Git 官方文档：在官方文档的 "git push" 部分中，可以找到关于 git push -f 命令的详细介绍。

官方文档通常是最权威的参考资料，可以从中了解到命令的语法、使用方式以及可能的风险和注意事项。

2. Pro Git 书籍：《Pro Git》是一本由 Git 专家撰写的书籍，该书详细介绍了 Git 的方方面面，包括 git push -f 命令的使用。

书中用简洁明了的语言解释了该命令的用途和注意事项，并提供了一些实际案例来帮助读者更好地理解命令的使用场景和结果。

3. Git Stack Overflow 问题：Git Stack Overflow 是一个面向开发者的问答社区，开发者在这里可以提出自己的问题并得到解答。

在 Git Stack Overflow 中搜索 "git push -f"，可以找到一些与该命令相关的问题和回答。

这些问题往往是实际应用场景中遇到的问题，对于理解命令的使用和潜在问题有很大帮助。

4. Git 参考手册：Git 参考手册是一份详细的 Git 命令参考资料，其中包含了对每个 Git 命令的介绍、选项和示例等信息。

4.9 服务器上的 Git - Git 守护进程Git 守护进程对于提供公共的，非授权的只读访问，我们可以抛弃 HTTP 协议，改用 Git 自己的协议，这主要是出于性能和速度的考虑。

Git 协议远比 HTTP 协议高效，因而访问速度也快，所以它能节省很多用户的时间。

重申一下，这一点只适用于非授权的只读访问。

如果建在防火墙之外的服务器上，那么它所提供的服务应该只是那些公开的只读项目。

如果是在防火墙之内的服务器上，可用于支撑大量参与人员或自动系统（用于持续集成或编译的主机）只读访问的项目，这样可以省去逐一配置 SSH 公钥的麻烦。

但不管哪种情形，Git 协议的配置设定都很简单。

基本上，只要以守护进程的形式运行该命令即可：git daemon --reuseaddr --base-path=/opt/git/ /opt/git/这里的 --reuseaddr 选项表示在重启服务前，不等之前的连接超时就立即重启。

而 --base-path 选项则允许克隆项目时不必给出完整路径。

最后面的路径告诉Git 守护进程允许开放给用户访问的仓库目录。

假如有防火墙，则需要为该主机的 9418 端口设置为允许通信。

以守护进程的形式运行该进程的方法有很多，但主要还得看用的是什么操作系统。

在 Ubuntu 主机上，可以用 Upstart 脚本达成。

编辑该文件：/etc/event.d/local-git-daemon加入以下内容：start on startupstop on shutdownexec /usr/bin/git daemon \--user=git --group=git \--reuseaddr \--base-path=/opt/git/ \/opt/git/respawn出于安全考虑，强烈建议用一个对仓库只有读取权限的用户身份来运行该进程—只需要简单地新建一个名为 git-ro 的用户（译注：新建用户默认对仓库文件不具备写权限，但这取决于仓库目录的权限设定。

4.8 服务器上的 Git - Gitolite Gitolite本节作为Gitolite的一个快速指南，指导基本的安装和设置。

不能完全替代随Gitolite自带的大量文档。

而且可能会随时改变本节内容，因此你也许想看看最新的版本。

Gitolite是在Git之上的一个授权层，依托sshd或者httpd来进行认证。

（概括：认证是确定用户是谁，授权是决定该用户是否被允许做他想做的事情）。

Gitolite允许你定义访问许可而不只作用于仓库，而同样于仓库中的每个branch和tag name。

你可以定义确切的人(或一组人)只能push特定的"refs"(或者branches或者tags)而不是其他人。

安装安装Gitolite非常简单, 你甚至不用读自带的那一大堆文档。

你需要一个unix 服务器上的账户；许多linux变种和solaris 10都已经试过了。

你不需要root 访问，假设git，perl，和一个openssh兼容的ssh服务器已经装好了。

在下面的例子里，我们会用git账户在gitserver进行。

Gitolite是不同于“服务”的软件 -- 其通过ssh访问, 而且每个在服务器上的userid都是一个潜在的“gitolite主机”。

我们在这里描述最简单的安装方法，对于其他方法，请参考其文档。

开始，在你的服务器上创建一个名为git的用户，然后以这个用户登录。

从你的工作站拷贝你的SSH公钥（也就是你用ssh-keygen默认生成的~/.ssh/id_dsa.pub文件），重命名为<yourname>.pub（我们这里使用scott.pub 作为例子）。

然后执行下面的命令：$ git clone git:///sitaramc/gitolite$ gitolite/install -ln# assumes $HOME/bin exists and is in your $PATH$ gitolite setup -pk $HOME/scott.pub最后一个命令在服务器上创建了一个名为gitolite-admin的Git仓库。

4.2 服务器上的 Git - 在服务器上部署 Git在服务器上部署 Git开始架设 Git 服务器前，需要先把现有仓库导出为裸仓库—即一个不包含当前工作目录的仓库。

做法直截了当，克隆时用 --bare 选项即可。

裸仓库的目录名一般以 .git 结尾，像这样：$ git clone --bare my_project my_project.gitCloning into bare repository 'my_project.git'...done.该命令的输出或许会让人有些不解。

其实 clone 操作基本上相当于 git init 加 git fetch，所以这里出现的其实是 git init 的输出，先由它建立一个空目录，而之后传输数据对象的操作并无任何输出，只是悄悄在幕后执行。

现在my_project.git 目录中已经有了一份 Git 目录数据的副本。

整体上的效果大致相当于：$ cp -Rf my_project/.git my_project.git但在配置文件中有若干小改动，不过对用户来讲，使用方式都一样，不会有什么影响。

它仅取出 Git 仓库的必要原始数据，存放在该目录中，而不会另外创建工作目录。

把裸仓库移到服务器上有了裸仓库的副本后，剩下的就是把它放到服务器上并设定相关协议。

假设一个域名为 的服务器已经架设好，并可以通过 SSH 访问，我们打算把所有 Git 仓库储存在 /opt/git 目录下。

只要把裸仓库复制过去：$ scp -r my_project.git user@:/opt/git现在，所有对该服务器有 SSH 访问权限，并可读取 /opt/git 目录的用户都可以用下面的命令克隆该项目：$ git clone user@:/opt/git/my_project.git如果某个 SSH 用户对 /opt/git/my_project.git 目录有写权限，那他就有推送权限。

3.6 Git 分支 - 分支的衍合分支的衍合把一个分支中的修改整合到另一个分支的办法有两种：merge 和 rebase（译注：rebase 的翻译暂定为“衍合”，大家知道就可以了。

）。

在本章我们会学习什么是衍合，如何使用衍合，为什么衍合操作如此富有魅力，以及我们应该在什么情况下使用衍合。

基本的衍合操作请回顾之前有关合并的一节（见图 3-27），你会看到开发进程分叉到两个不同分支，又各自提交了更新。

图 3-27. 最初分叉的提交历史。

之前介绍过，最容易的整合分支的方法是 merge 命令，它会把两个分支最新的快照（C3 和 C4）以及二者最新的共同祖先（C2）进行三方合并，合并的结果是产生一个新的提交对象（C5）。

如图 3-28 所示：图 3-28. 通过合并一个分支来整合分叉了的历史。

其实，还有另外一个选择：你可以把在 C3 里产生的变化补丁在 C4 的基础上重新打一遍。

在 Git 里，这种操作叫做衍合（rebase）。

有了 rebase 命令，就可以把在一个分支里提交的改变移到另一个分支里重放一遍。

在上面这个例子中，运行：$ git checkout experiment$ git rebase masterFirst, rewinding head to replay your work on top of it...Applying: added staged command它的原理是回到两个分支最近的共同祖先，根据当前分支（也就是要进行衍合的分支 experiment）后续的历次提交对象（这里只有一个 C3），生成一系列文件补丁，然后以基底分支（也就是主干分支 master）最后一个提交对象（C4）为新的出发点，逐个应用之前准备好的补丁文件，最后会生成一个新的合并提交对象（C3'），从而改写 experiment 的提交历史，使它成为 master 分支的直接下游，如图 3-29 所示：图 3-29. 把 C3 里产生的改变到 C4 上重演一遍。

专为设计师而写的GitHub快速入门教程教本教本GitHub 是一个基于 Git 版本控制系统的在线代码托管平台。

它为设计师和开发人员提供了一个共享和协作的平台，使他们能够更好地管理和追踪代码的变更。

下面是一份专为设计师而写的 GitHub 快速入门教程教本，帮助你了解如何使用 GitHub 进行设计项目的版本控制和协作。

第一步：创建一个 GitHub 账号第二步：创建一个新的仓库在 GitHub 主页的右上角，点击加号按钮并选择 "New repository"。

在弹出的界面中，填写仓库的名称和描述。

选择公开或私有的仓库，并勾选 "Initialize this repository with a README"，然后点击 "Create repository" 按钮。

第三步：克隆仓库到本地在你的仓库主页上，你会看到一个绿色的按钮，上面写着 "Code"，点击它并选择 "HTTPS"。

复制仓库的链接地址。

然后，在你的本地电脑上打开终端或命令提示符，使用 `git clone` 命令加上仓库的链接地址来克隆仓库到本地。

例如：``````第四步：创建分支在进行任何更改之前，你应该创建一个新的分支来进行你的工作。

使用 `git branch` 命令来创建一个新的分支，并使用 `git checkout` 命令切换到该分支。

例如：```git branch new-featuregit checkout new-feature```第五步：进行设计工作使用 `git add` 命令将你的设计文件添加到暂存区。

例如：```git add design-file.psd```例如：``````第六步：推送更改到 GitHub当你完成了一段时间的设计工作后，你可以将你的更改推送到你的GitHub 仓库。

使用 `git push` 命令将你的分支推送到远程仓库。

一天彻底搞懂Git《Git原理详解及实用指南》老钱点评：这不是乔杉嘛，他也会搞IT？他头发怎么掉光了小册简介「Git 好难啊！」不会用Git 和会用Git的人都这么说。

随着这几年 GitHub 的流行，Git 已经是一个程序员逃不过的技术项，但很多人却纷纷倒在了学习它的路上。

而且，出于工作原因而不得不用 Git 的人，有不少在工作中对 Git 也是能不用就不用，生怕哪个命令用错就把公司的代码库毁掉了 。

而那些对 Git 掌握得比较好的少数人，就像团队中的神一样，在同事遇到Git 相关的问题的时候用各种风骚操作来拯救队友于水火。

学不会、学不好Git 的人，其实多数并不是不愿意学。

很多人都会尝试去网上找Git 教程、去社区请教高手、在公司咨询同事，但转了一大圈下来，依然没有搞懂，甚至有可能越来越糊涂。

- 你刚才输入的这个Git 指令是什么意思？- 意思是 XXX。

- 可你上次跟我说它的意思是 YYY 啊？- 嗯对，不同的场景不同的用法，上次是YYY。

- ……好吧。

另外你上次帮我解决这个问题用的是另一个指令 zzz 啊？- 嗯对，那个也能解决，但这次用这个指令更适合，因为 @#￥@%*&。

- ……- 懂了吗？不懂的话还可以问我，没事的。

- ……Git 学习到底难在哪？Git 的学习曲线很不友好：想上手很容易，只要学会commit、push、pull 等几个指令，就能够初步地使用它；但如果想要更进一步，让自己能够在团队项目中和朋友或同事自由合作，却又很难。

那么 Git 到底难在哪呢？其实关键在于一点：概念。

Git 的概念，是由一套完整的思维逻辑所构成的。

你不能从多个角度分步理解它，而是要把它作为一个整体一下子吃掉；而同时这个「整体」由于过于复杂，又实在有点难以一口吞。

颇有点悖论的意味。

很多人在使用 Git 一段时间后，会觉得 Git 有点复杂和混乱：- 为什么要 commit 后再 push 这么啰嗦，而不能直接提交到中央仓库？- reset 这个指令为什么这么神奇，好多看起来并不相似的操作却都要用到它？它到底是干嘛的？- revert 和rebase 都可以撤销历史提交？它们的区别在哪？什么，你说 reset 也行？类似的问题其实还有很多。

4.3 服务器上的 Git - 生成 SSH 公钥生成 SSH 公钥大多数 Git 服务器都会选择使用 SSH 公钥来进行授权。

系统中的每个用户都必须提供一个公钥用于授权，没有的话就要生成一个。

生成公钥的过程在所有操作系统上都差不多。

首先先确认一下是否已经有一个公钥了。

SSH 公钥默认储存在账户的主目录下的 ~/.ssh 目录。

进去看看：$ cd ~/.ssh$ lsauthorized_keys2 id_dsa known_hostsconfig id_dsa.pub关键是看有没有用 something 和 something.pub 来命名的一对文件，这个something 通常就是 id_dsa 或 id_rsa。

有 .pub 后缀的文件就是公钥，另一个文件则是密钥。

假如没有这些文件，或者干脆连 .ssh 目录都没有，可以用ssh-keygen 来创建。

该程序在 Linux/Mac 系统上由 SSH 包提供，而在 Windows 上则包含在 MSysGit 包里：$ ssh-keygenGenerating public/private rsa key pair.Enter file in which to save the key (/Users/schacon/.ssh/id_rsa): Enter passphrase (empty for no passphrase):Enter same passphrase again:Your identification has been saved in /Users/schacon/.ssh/id_rsa. Your public key has been saved in /Users/schacon/.ssh/id_rsa.pub.The key fingerprint is:43:c5:5b:5f:b1:f1:50:43:ad:20:a6:92:6a:1f:9a:3aschacon@agadorlaptop.local它先要求你确认保存公钥的位置（.ssh/id_rsa），然后它会让你重复一个密码两次，如果不想在使用公钥的时候输入密码，可以留空。