1.5 起步 - 初次运行 Git 前的配置

本文介绍如何配置Git工作环境,包括用户信息、文本编辑器及差异分析工具等设置。

初次运行 Git 前的配置

一般在新的系统上,我们都需要先配置下自己的 Git 工作环境。配置工作只需一次,以后升级时还会沿用现在的配置。当然,如果需要,你随时可以用相同的命令修改已有的配置。

Git 提供了一个叫做 git config 的工具(译注:实际是 git-config 命令,只不过可以通过 git 加一个名字来呼叫此命令。),专门用来配置或读取相应的工作环境变量。而正是由这些环境变量,决定了 Git 在各个环节的具体工作方式和行为。这些变量可以存放在以下三个不同的地方:

  • /etc/gitconfig 文件:系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system选项,读写的就是这个文件。
  • ~/.gitconfig 文件:用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global选项,读写的就是这个文件。
  • 当前项目的 Git 目录中的配置文件(也就是工作目录中的 .git/config 文件):这里的配置仅仅针对当前项目有效。每一个级别的配置都会覆盖上层的相同配置,所以 .git/config 里的配置会覆盖/etc/gitconfig 中的同名变量。

在 Windows 系统上,Git 会找寻用户主目录下的 .gitconfig 文件。主目录即 $HOME 变量指定的目录,一般都是 C:\Documents and Settings\$USER。此外,Git 还会尝试找寻 /etc/gitconfig 文件,只不过看当初 Git 装在什么目录,就以此作为根目录来定位。

用户信息

第一个要配置的是你个人的用户名称和电子邮件地址。这两条配置很重要,每次 Git 提交时都会引用这两条信息,说明是谁提交了更新,所以会随更新内容一起被永久纳入历史记录:

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

如果用了 --global 选项,那么更改的配置文件就是位于你用户主目录下的那个,以后你所有的项目都会默认使用这里配置的用户信息。如果要在某个特定的项目中使用其他名字或者电邮,只要去掉 --global选项重新配置即可,新的设定保存在当前项目的 .git/config 文件里。

文本编辑器

接下来要设置的是默认使用的文本编辑器。Git 需要你输入一些额外消息的时候,会自动调用一个外部文本编辑器给你用。默认会使用操作系统指定的默认编辑器,一般可能会是 Vi 或者 Vim。如果你有其他偏好,比如 Emacs 的话,可以重新设置:

$ git config --global core.editor emacs

差异分析工具

还有一个比较常用的是,在解决合并冲突时使用哪种差异分析工具。比如要改用 vimdiff 的话:

$ git config --global merge.tool vimdiff

Git 可以理解 kdiff3,tkdiff,meld,xxdiff,emerge,vimdiff,gvimdiff,ecmerge,和 opendiff 等合并工具的输出信息。当然,你也可以指定使用自己开发的工具,具体怎么做可以参阅第七章。

查看配置信息

要检查已有的配置信息,可以使用 git config --list 命令:

$ git config --list
user.name=Scott Chacon
user.email=schacon@gmail.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto
...

有时候会看到重复的变量名,那就说明它们来自不同的配置文件(比如 /etc/gitconfig 和~/.gitconfig),不过最终 Git 实际采用的是最后一个。

也可以直接查阅某个环境变量的设定,只要把特定的名字跟在后面即可,像这样:

$ git config user.name
Scott Chacon
本文来自 http://git-scm.com/ 保存下来,方便自己查阅。
<think> 我们正在解决Git推送时出现的`! [rejected] dev-1.5-donghu -> dev-1.5-donghu (non-fast-forward)`错误。根据引用[2]和[4],这个错误通常是因为远程分支包含本地分支没有的提交(即远程分支比本地分支超),导致推送被拒绝。解决这个问题的核心是先将远程的变更合并到本地,然后再推送。 ### 错误原因分析 - **核心问题**:本地分支`dev-1.5-donghu`的提交历史与远程分支`dev-1.5-donghu`的提交历史出现分叉(diverged),即远程分支有你没有的新提交,而你的本地提交基于旧版本。 - **常见场景**: - 在推送之,其他人已经向远程分支推送了新的提交。 - 你在推送之没有拉取最新的远程分支状态(或者拉取后出现了冲突需要手动解决)。 - 本地分支和远程分支的提交历史不一致(比如远程分支被强制推送过)。 ### 逐步解决方法 #### 方法1:使用`git pull`合并远程更改(推荐) 这是最安全的做法,它会将远程分支的更改合并到本地分支,然后你就可以推送合并后的结果。 1. **拉取远程分支并合并**: 在终端中执行以下命令(确保当在分支`dev-1.5-donghu`上): ```bash git pull origin dev-1.5-donghu ``` - 如果拉取过程中没有冲突,Git会自动合并并生成一个合并提交。然后你可以将合并后的结果推送到远程: ```bash git push origin dev-1.5-donghu ``` 2. **处理合并冲突**: - 如果在`git pull`时遇到冲突,Git会中止合并并标记冲突文件。你需要手动解决冲突: 1. 使用`git status`查看冲突文件。 2. 打开冲突文件,找到冲突标记(`<<<<<<<`, `=======`, `>>>>>>>`),并修改为正确的内容。 3. 解决冲突后,将文件标记为已解决: ```bash git add <冲突的文件路径> ``` 4. 完成合并: ```bash git commit -m "解决合并冲突" ``` 5. 推送合并后的结果: ```bash git push origin dev-1.5-donghu ``` #### 方法2:使用`git pull --rebase`变基(推荐,保持线性历史) 如果你希望避免合并提交,保持提交历史的线性,可以使用变基(rebase): 1. **拉取远程分支并变基**: ```bash git pull --rebase origin dev-1.5-donghu ``` - 这个命令会将你的本地提交“移动”到更新后的远程分支顶端。 2. **处理变基冲突**: - 如果在变基过程中出现冲突,Git会暂停变基。你需要: 1. 手动解决冲突(同上)。 2. 使用`git add`标记冲突已解决。 3. 继续变基: ```bash git rebase --continue ``` 4. 重复以上步骤直到所有提交都应用完成。 - 如果变基过程中想放弃,可以运行: ```bash git rebase --abort ``` 3. **推送变更**: 变基完成后,使用强制推送(因为变基改变了提交历史): ```bash git push --force-with-lease origin dev-1.5-donghu ``` **注意**:`--force-with-lease`比`--force`更安全,它会检查远程分支是否被其他人更新,避免覆盖他人提交。如果只有你一个人在操作,也可以使用`-f`(`--force`)。 #### 方法3:强制推送(慎用) 如果确定远程分支的更改不重要(比如是测试提交),或者你就是要用本地分支覆盖远程分支,可以使用强制推送。**但请谨慎使用,因为它会覆盖远程分支的历史,可能导致他人工作丢失。** ```bash git push --force origin dev-1.5-donghu ``` 或者更安全的: ```bash git push --force-with-lease origin dev-1.5-donghu ``` ### 预防措施 1. **推送先拉取**:养成在`git push`之先执行`git pull`的习惯。 2. **使用`--set-upstream`**:确保本地分支设置了正确的上游分支(跟踪分支),这样可以直接用`git pull`而不需要指定远程分支名。 3. **团队协作规范**:团队中约定避免强制推送,除非在特定分支(如个人分支)上。 ### 验证 成功推送后,可以通过以下命令检查状态: ```bash git status ``` 输出应显示: ``` Your branch is up to date with 'origin/dev-1.5-donghu'. ``` ### 相关问题 1. 如何设置Git分支的上游(upstream)以简化推送操作? 2. 在团队协作中,如何避免频繁出现合并冲突? 3. Git中的变基(rebase)和合并(merge)有什么区别,分别适用于什么场景? 通过上述方法,你应该能够解决`non-fast-forward`错误。如果问题仍然存在,请检查远程分支是否存在,或者是否有权限问题。 [^1]: 引用[2],[4],[5] </think> ### 解决 Git 推送出现 `! [rejected] dev-1.5-donghu -> dev-1.5-donghu (non-fast-forward)` 错误 #### 错误原因分析 该错误表示**远程分支包含本地没有的新提交**(通常是因为其他人已推送代码或远程存在README等初始化文件),导致 Git 拒绝覆盖历史记录。核心矛盾是本地提交基于旧版本代码,而远程已有更新[^2][^4][^5]。 --- ### 逐步解决方案 #### ✅ 方法1:合并远程更改(推荐) ```bash # 1. 拉取远程最新代码并尝试自动合并 git pull origin dev-1.5-donghu # 2. 解决可能出现的冲突(若有) # 手动编辑冲突文件 → git add <file> → git commit # 3. 重新推送 git push origin dev-1.5-donghu ``` #### ✅ 方法2:变基操作(保持线性提交历史) ```bash # 1. 拉取远程代码并变基(将本地提交"移到"远程最新提交之后) git pull --rebase origin dev-1.5-donghu # 2. 解决冲突(若有) # 编辑冲突 → git add <file> → git rebase --continue # 3. 强制推送(因历史记录已改变) git push --force-with-lease origin dev-1.5-donghu # 比--force更安全 ``` #### ️ 方法3:强制覆盖(慎用!仅限个人分支) ```bash git push --force origin dev-1.5-donghu ``` > **风险提示**:会覆盖远程分支所有提交,可能导致团队协作问题[^3]。使用确保: > 1. 这是你的私有分支 > 2. 远程无重要新提交 > 3. 已备份代码 --- ### 关键预防措施 1. **规范初始化新分支**: ```bash git push -u origin dev-1.5-donghu # -u 自动设置跟踪 ``` 2. **推送总是先拉取**: ```bash git pull --rebase && git push # 变基式拉取更整洁 ``` 3. **定期同步远程状态**: ```bash git fetch --prune # 删除本地无效远程分支引用 ``` --- ### 错误场景验证 ```bash git log --graph --oneline --all # 查看提交历史拓扑图 ``` 输出示例: ``` * 远程提交 C (origin/dev-1.5-donghu) | * 本地提交 B (dev-1.5-donghu) # 分叉点 |/ * 共同祖先提交 A ``` > 此结构表明需合并/变基[^2][^5] --- ### 相关问题 1. 如何避免团队协作中的 Git 提交冲突? 2. `git merge` 和 `git rebase` 的核心区别是什么? 3. 强制推送(`git push -f`)后如何恢复丢失的提交?[^3] 通过以上步骤可彻底解决非快进错误,同时保持提交历史的完整性[^4][^5]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值