git项目实战

最新推荐文章于 2024-06-22 15:35:31 发布

shuyong1999

最新推荐文章于 2024-06-22 15:35:31 发布

阅读量3.8k

点赞数

分类专栏： git 文章标签： git windows 文本编辑工具跨平台工作

本文链接：https://blog.csdn.net/shuyong1999/article/details/7185041

版权

git 专栏收录该内容

8 篇文章 0 订阅

订阅专栏

1.准备

debian6,

http://roclinux.cn/?p=184,一个非常不错的git介绍

2.安装

sudo aot-get install git

3.创建服务根目录

sudo mkdir /srv/gitroot

sudo mkdir /srv/gitroot/PHPWebSite //用PHP-Yii做的小型网站

4.配置git

4.1创建库sudo git init

Initialized empty Git repository in /srv/gitroot/PHPWebSite/.git/

4.2配置库

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

/etc/gitconfig 文件：系统中对所有用户都普遍适用的配置。若使用 git config 时用 --system 选项，读写的就是这个文件。
~/.gitconfig 文件：用户目录下的配置文件只适用于该用户。若使用 git config 时用 --global 选项，读写的就是这个文件。
当前项目的 git 目录中的配置文件（也就是工作目录中的 .git/config 文件）：这里的配置仅仅针对当前项目有效。

每一个级别的配置都会覆盖上层的相同配置，所以 .git/config 里的配置会覆盖 /etc/gitconfig 中的同名变量。

4.2.1用户信息

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

git config --global user.name "liushuyong"
git config --global user.email liushuyong@novel-supertv.com

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

4.2.2文本编辑器

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

$ git config --global core.editor vim

    
    
     
     4.2.3差异分析工具  
     
             还有一个比较常用的是，在解决合并冲突时使用哪种差异分析工具。比如要改用 vimdiff 的话： 
     
     
      
      $ git config --global merge.tool meld 
      
       
      
      Git 可以理解 kdiff3，tkdiff，meld，xxdiff，emerge，vimdiff，gvimdiff，ecmerge，和 opendiff 等合并工具的输出信息。当然，你也可以指定使用自己开发的工具，具体怎么做可以参阅第七章。

4.2.4Git中的着色

git config --global color.ui true

4.2.5格式化与空白

格式化与空白是许多开发人员在协作时，特别是在跨平台情况下，遇到的令人头疼的细小问题。由于编辑器的不同或者Windows程序员在跨平台项目中的文件行尾加入了回车换行符，一些细微的空格变化会不经意地进入大家合作的工作或提交的补丁中。不用怕，Git 的一些配置选项会帮助你解决这些问题。

4.2.5.1core.autocrlf

假如你正在Windows上写程序，又或者你正在和其他人合作，他们在Windows上编程，而你却在其他系统上，在这些情况下，你可能会遇到行尾结束符问题。这是因为Windows使用回车和换行两个字符来结束一行，而Mac和Linux只使用换行一个字符。虽然这是小问题，但它会极大地扰乱跨平台协作。

Git可以在你提交时自动地把行结束符CRLF转换成LF，而在签出代码时把LF转换成CRLF。用core.autocrlf来打开此项功能，如果是在Windows系统上，把它设置成true，这样当签出代码时，LF会被转换成CRLF：

$ git config --global core.autocrlf true

Linux或Mac系统使用LF作为行结束符，因此你不想 Git 在签出文件时进行自动的转换；当一个以CRLF为行结束符的文件不小心被引入时你肯定想进行修正，把core.autocrlf设置成input来告诉 Git 在提交时把CRLF转换成LF，签出时不转换：

$ git config --global core.autocrlf input

这样会在Windows系统上的签出文件中保留CRLF，会在Mac和Linux系统上，包括仓库中保留LF。

如果你是Windows程序员，且正在开发仅运行在Windows上的项目，可以设置false取消此功能，把回车符记录在库中：

$ git config --global core.autocrlf false

4.2.5.2core.whitespace

Git预先设置了一些选项来探测和修正空白问题，其4种主要选项中的2个默认被打开，另2个被关闭，你可以自由地打开或关闭它们。

默认被打开的2个选项是trailing-space和space-before-tab，trailing-space会查找每行结尾的空格，space-before-tab会查找每行开头的制表符前的空格。

默认被关闭的2个选项是indent-with-non-tab和cr-at-eol，indent-with-non-tab会查找8个以上空格（非制表符）开头的行，cr-at-eol让 Git 知道行尾回车符是合法的。

设置core.whitespace，按照你的意图来打开或关闭选项，选项以逗号分割。通过逗号分割的链中去掉选项或在选项前加-来关闭，例如，如果你想要打开除了cr-at-eol之外的所有选项：

$ git config --global core.whitespace \
    trailing-space,space-before-tab,indent-with-non-tab

当你运行git diff命令且为输出着色时，Git 探测到这些问题，因此你也许在提交前能修复它们，当你用git apply打补丁时同样也会从中受益。如果正准备运用的补丁有特别的空白问题，你可以让 Git 发警告：

$ git apply --whitespace=warn <patch>

或者让 Git 在打上补丁前自动修正此问题：

$ git apply --whitespace=fix <patch>

这些选项也能运用于衍合。如果提交了有空白问题的文件但还没推送到上流，你可以运行带有--whitespace=fix选项的rebase来让Git在重写补丁时自动修正它们。

4.2.6指定特殊的提交信息格式

我们的第一项任务是指定每一条提交信息都必须遵循某种特殊的格式。作为演示，假定每一条信息必须包含一条形似 "ref: 1234"这样的字符串，因为我们需要把每一次提交和项目的问题追踪系统。我们要逐一检查每一条推送上来的提交内容，看看提交信息是否包含这么一个字符串，然后，如果该提交里不包含这个字符串，以非零返回值退出从而拒绝此次推送。

把 $newrev 和 $oldrev 变量的值传给一个叫做 git rev-list 的 Git plumbing 命令可以获取所有提交内容的 SHA-1 值列表。git rev-list 基本类似git log 命令，但它默认只输出 SHA-1 值而已，没有其他信息。所以要获取由 SHA 值表示的从一次提交到另一次提交之间的所有 SHA 值，可以运行：

$ git rev-list 538c33..d14fc7
d14fc7c847ab946ec39590d87783c69b031bdfb7
9f585da4401b0a3999e84113824d15245c13f0be
234071a1be950e2a8d078e6141f5cd20c1e61ad3
dfa04c9ef3d5197182f13fb5b9b1fb7717d2222a
17716ec0f1ff5c77eff40b7fe912f9f6cfd0e475

截取这些输出内容，循环遍历其中每一个 SHA 值，找出与之对应的提交信息，然后用正则表达式来测试该信息包含的格式话的内容。

下面要搞定如何从所有的提交内容中提取出提交信息。使用另一个叫做 git cat-file 的 Git plumbing 工具可以获得原始的提交数据。我们将在第九章了解到这些 plumbing 工具的细节；现在暂时先看一下这条命令的输出：

$ git cat-file commit ca82a6
tree cfda3bf379e4f8dba8717dee55aab78aef7f4daf
parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
author Scott Chacon <schacon@gmail.com> 1205815931 -0700
committer Scott Chacon <schacon@gmail.com> 1240030591 -0700

changed the version number

通过 SHA-1 值获得提交内容中的提交信息的一个简单办法是找到提交的第一行，然后取从它往后的所有内容。可以使用 Unix 系统的 sed 命令来实现该效果：

$ git cat-file commit ca82a6 | sed '1,/^$/d'
changed the version number

这条咒语从每一个待提交内容里提取提交信息，并且会在提取信息不符合要求的情况下退出。为了退出脚本和拒绝此次推送，返回一个非零值。整个脚本大致如下：

$regex = /\[ref: (\d+)\]/

# 指定提交信息格式
def check_message_format
  missed_revs = `git rev-list #{$oldrev}..#{$newrev}`.split("\n")
  missed_revs.each do |rev|
    message = `git cat-file commit #{rev} | sed '1,/^$/d'`
    if !$regex.match(message)
      puts "[POLICY] Your message is not formatted correctly"
      exit 1
    end
  end
end
check_message_format

把这一段放在 update 脚本里，所有包含不符合指定规则的提交都会遭到拒绝。

4.2.7查看配置信息

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

$ git config --list

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

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

$ git config user.name

4.2.8权限配置

5.git使用大全

5.1创建私有的版本库

mkdir -p /home/shuyong/myGitRoot

5.2远程获取一个git库 git-clone

git clone ssh://root@192.168.18.49/git/5602 /home/shuyong/myGitRoot

另外，通过git-clone获取的远端git库，只包含了远端git库的当前工作分支。如果想获取其它分支信息，需要使用”git-branch –r” 来查看，如果需要将远程的其它分支代码也获取过来，可以使用命令” git checkout -b 本地分支名远程分支名”，其中，远程分支名为git-branch –r所列出的分支名，一般是诸如“origin/分支名”的样子。如果本地分支名已经存在，则不需要“-b”参数。

5.3从远程获取一个git分支 – git-pull

与git-clone不同， git-pull可以从任意一个git库获取某个分支的内容。用法如下：
git-pull username@ipaddr: 远端repository名远端分支名:本地分支名。这条命令将从远端git库的远端分支名获取到本地git库的一个本地分支中。其中，如果不写本地分支名，则默认pull到本地当前分支。
需要注意的是，git-pull也可以用来合并分支。和git-merge的作用相同。因此，如果你的本地分支已经有内容，则git-pull会合并这些文件，如果有冲突会报警。

5.4 将本地分支内容提交到远端分支 – git-push

git-push和git-pull正好想反，是将本地某个分支的内容提交到远端某个分支上。用法：
git-push username@ipaddr: 远端repository名本地分支名:远端分支名。这条命令将本地git库的一个本地分支push到远端git库的远端分支名中。

sudo git push origin master:tmp

origin:远端repository名

master:本地分支名

tmp:远端分支名

需要格外注意的是，git-push好像不会自动合并文件。这点我的试验表明是这样，但我不能确认是否是我用错了。因此，如果git-push时，发生了冲突，就会被后push的文件内容强行覆盖，而且没有什么提示。这在合作开发时是很危险的事情。

5.5库的逆转与恢复 – git-reset

库的逆转与恢复除了用来进行一些废弃的研发代码的重置外，还有一个重要的作用。比如我们从远程clone了一个代码库，在本地开发后，准备提交回远程。但是本地代码库在开发时，有功能性的commit，也有出于备份目的的commit等等。总之，commit的日志中有大量无用log，我们并不想把这些log在提交回远程时也提交到库中。因此，就要用到git-reset。
Git-reset的概念比较复杂。它的命令形式：git-reset [--mixed | --soft | --hard] [<commit-ish>]
命令的选项：
--mixed
这个是默认的选项。如git-reset [--mixed] dev1^(dev1^的定义可以参见2.6.5)。它的作用仅是重置分支状态到dev1^, 但是却不改变任何工作文件的内容。即，从dev1^到dev1的所有文件变化都保留了，但是dev1^到dev1之间的所有commit日志都被清除了，而且，发生变化的文件内容也没有通过git-add标识，如果您要重新commit，还需要对变化的文件做一次git-add。这样，commit后，就得到了一份非常干净的提交记录。
--soft
相当于做了git-reset –mixed，后，又对变化的文件做了git-add。如果用了该选项，就可以直接commit了。
--hard
这个命令就会导致所有信息的回退，包括文件内容。一般只有在重置废弃代码时，才用它。执行后，文件内容也无法恢复回来了。

6.git配合SVN库使用：git-svn

本站文章除注明转载外，均为本站原创或者翻译。
本站文章欢迎各种形式的转载，但请18岁以上的转载者注明文章出处，尊重我的劳动，也尊重你的智商；
本站部分原创和翻译文章提供markdown格式源码，欢迎使用文章源码进行转载；
本文标题：git乱码解决方案汇总
本文链接：http://zengrong.net/post/1249.htm

2011-10-24更新：从一篇链接到本篇文章的文章(我对这篇文章提出的与windows患者的相处之道深感赞同)找到了一个“终极”解决方案，但我没有测试。

我一直是在cygwin下使用git，辅以TortoiseGit。使用上没什么问题，但今天在处理一个有中文文件名的项目时却出现文件名乱码的问题。

情况是这样的：

在一个使用cygwin的bash提交的git项目中，已经完成了所有的提交，但使用TortoiseGit查看的时候，却发现仍有文件没有提交，甚至是有文件还处于未暂存的状态。于是使用TortoiseGit提交；
再次用cygwin下的git status查看，这次又发现了未提交的情况。再次用git commit命令行提交；
回到TortoiseGit下查看，问题又出现了！此时准备返回两次提交前的版本，却因为文件名乱码的问题，无法返回了！

搜索一番，发现git文件名、log乱码，是普遍问题，这其中有编码的原因，也有跨平台的原因。因为git是从linux移植过来，默认采用UTF-8编码。而Windows默认使用UTF-16编码来保存文件名，应该就是这些不同的处理方式造成了乱码。下面是解决方案：

乱码情景1

在cygwin中，使用git add添加要提交的文件的时候，如果文件名是中文，会显示形如274\232\350\256\256\346\200\273\347\273\223.png的乱码。

解决方案：

在bash提示符下输入：

git config –global core.quotepath false

ore.quotepath设为false的话，就不会对0×80以上的字符进行quote。中文显示正常。

乱码情景2

在MsysGit中，使用git log显示提交的中文log乱码。

解决方案：

设置git gui的界面编码

git config –global gui.encoding utf-8

设置 commit log 提交时使用 utf-8 编码，可避免服务器上乱码，同时与linix上的提交保持一致！

git config –global i18n.commitencoding utf-8

使得在 $ git log 时将 utf-8 编码转换成 gbk 编码，解决Msys bash中git log 乱码。

git config –global i18n.logoutputencoding gbk

使得 git log 可以正常显示中文（配合i18n.logoutputencoding = gbk)，在 /etc/profile 中添加：

export LESSCHARSET=utf-8

乱码情景3

在MsysGit自带的bash中，使用ls命令查看中文文件名乱码。cygwin没有这个问题。

解决方案：

使用ls –show-control-chars命令来强制使用控制台字符编码显示文件名，即可查看中文文件名。

为了方便使用，可以编辑/etc/git-completion.bash ，新增一行 alias ls=”ls –show-control-chars”

最终，还是没能解决最开始我提到的文件名提交乱码的问题。不过倒是有了一个新发现： 使用git gui命令，在MsysGit下，看到的中文文件名为正常；而在cygwin下，看到的中文文件名为乱码。

同样的，如果一直使用TortoiseGit（实际调用MsysGit）提交，那么中文文件名没问题；一直使用cygwin提交，中文文件名也没问题。但一定不能交叉使用。这应该是两个平台默认处理中文文件名的方式不同造成的。

分别设置LANG、LC_CTYPE、LC_ALL参数为同样的编码，问题依旧。

cygwin官方网站提到了非拉丁语文件名的问题，也许研究后能解决该吧：Chapter 2. Setting Up Cygwin

这里还有一篇讲解Linux系统编码文章：locale的设定及其LANG、LC_ALL、LANGUAGE环境变量的区别

貌似终极的解决办法是通过修改git和TortoiseGit源码实现的，有网友这么做了：让Windows下Git和TortoiseGit支持中文文件名/UTF-8

又一个“终极”解决方案（来自）：

在操作git时，把区域设置修改为中文GBK。这之后就可以进行git相关操作了。

在终端中跟windows保持一致

^? View Code BASH

export LC_ALL=zh_CN.GBK; export LANG=zh_CN.GBK
terminal -> set charactor encoding -> gbk

切换回linux默认

^? View Code BASH

export LC_ALL=en_US.utf8; export LANG=en_US.utf8
terminal -> set charactor encoding -> unicode(utf-8)

改变文件名的编码

如果已经造成乱码的恶果，还可以在utf8和gbk之间切换文件名。真的修改，而不是像上面那样修改显示的（解码的）效果。

^? View Code BASH

convmv <filename> -f utf8 -t gbk

例外。convmv在fat32的U盘上运行无效，估计是fat32不允许非法编码。

shuyong1999

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
1
评论
git项目实战

1.准备 debian6, http://roclinux.cn/?p=184,一个非常不错的git介绍2.安装 sudo aot-get install git 3.创建服务根目录 sudo mkdir /srv/gitroot sudo mkdir /srv/gitroot/PHPW
复制链接

扫一扫

专栏目录