标签 Git 下的文章

BUP 并不单纯是 Git, 而是一款基于 Git 的软件. 一般情况下, 我使用 rsync 来备份我的文件, 而且迄今为止一直工作的很好. 唯一的不足就是无法把文件恢复到某个特定的时间点. 因此, 我开始寻找替代品, 结果发现了 BUP, 一款基于 git 的软件, 它将数据存储在一个仓库中, 并且有将数据恢复到特定时间点的选项.

要使用 BUP, 你先要初始化一个空的仓库, 然后备份所有文件. 当 BUP 完成一次备份是, 它会创建一个还原点, 你可以过后还原到这里. 它还会创建所有文件的索引, 包括文件的属性和验校和. 当要进行下一个备份时, BUP 会对比文件的属性和验校和, 只保存发生变化的数据. 这样可以节省很多空间.

安装 BUP (在 Centos 6 & 7 上测试通过)

首先确保你已经安装了 RPMFORGE 和 EPEL 仓库

[techarena51@vps ~]$ sudo yum groupinstall "Development Tools"
[techarena51@vps ~]$ sudo yum install python python-devel
[techarena51@vps ~]$ sudo yum install fuse-python pyxattr pylibacl
[techarena51@vps ~]$ sudo yum install perl-Time-HiRes
[techarena51@vps ~]$ git clone git://github.com/bup/bup
[techarena51@vps ~]$ cd bup
[techarena51@vps ~]$ make
[techarena51@vps ~]$ make test
[techarena51@vps ~]$ sudo make install

对于 debian/ubuntu 用户, 你可以使用 "apt-get build-dep bup". 要获得更多的信息, 可以查看 https://github.com/bup/bup

在 CentOS 7 上, 当你运行 "make test" 时可能会出错, 但你可以继续运行 "make install".

第一步时初始化一个空的仓库, 就像 git 一样.

[techarena51@vps ~]$ bup init

默认情况下, bup 会把仓库存储在 "~/.bup" 中, 但你可以通过设置环境变量 "export BUP\_DIR=/mnt/user/bup" 来改变设置.

然后, 创建所有文件的索引. 这个索引, 就像之前讲过的那样, 存储了一系列文件和它们的属性及 git 目标 id (sha1 哈希表). (属性包括了软链接, 权限和不可改变字节)

bup index /path/to/file
bup save -n nameofbackup /path/to/file

#Example
[techarena51@vps ~]$ bup index /var/www/html
Indexing: 7973, done (4398 paths/s).
bup: merging indexes (7980/7980), done.

[techarena51@vps ~]$ bup save -n techarena51 /var/www/html

Reading index: 28, done.
Saving: 100.00% (4/4k, 28/28 files), done.
bloom: adding 1 file (7 objects).
Receiving index from server: 1268/1268, done.
bloom: adding 1 file (7 objects).

"BUP save" 会把所有内容分块, 然后把它们作为对象储存. "-n" 选项指定备份名.

你可以查看备份列表和已备份文件.

[techarena51@vps ~]$ bup ls
local-etc    techarena51  test
#Check for a list of backups available for my site
[techarena51@vps ~]$ bup ls techarena51
2014-09-24-064416  2014-09-24-071814  latest
#Check for the files available in these backups
[techarena51@vps ~]$ bup ls techarena51/2014-09-24-064416/var/www/html
apc.php                      techarena51.com              wp-config-sample.php         wp-load.php

在同一个服务器上备份文件从来不是一个好的选择. BUP 允许你远程备份网页文件, 但你必须保证你的 SSH 密钥和 BUP 都已经安装在远程服务器上.

bup index path/to/dir
bup save-r remote-vps.com -n backupname path/to/dir

例子: 备份 "/var/www/html" 文件夹

[techarena51@vps ~]$bup index /var/www/html
[techarena51@vps ~]$ bup save -r [email protected]: -n techarena51 /var/www/html
Reading index: 28, done.
Saving: 100.00% (4/4k, 28/28 files), done.
bloom: adding 1 file (7 objects).
Receiving index from server: 1268/1268, done.
bloom: adding 1 file (7 objects).

恢复备份

登入远程服务器并输入下面的命令

[techarena51@vps ~]$bup restore -C ./backup techarena51/latest

#Restore an older version of the entire working dir elsewhere
[techarena51@vps ~]$bup restore -C /tmp/bup-out /testrepo/2013-09-29-195827
#Restore one individual file from an old backup
[techarena51@vps ~]$bup restore -C /tmp/bup-out /testrepo/2013-09-29-201328/root/testbup/binfile1.bin

唯一的缺点是你不能把文件恢复到另一个服务器, 你必须通过 SCP 或者 rsync 手动复制文件.

通过集成的 web 服务器查看备份.

bup web
#specific port
bup web :8181

你可以使用 shell 脚本来运行 bup, 并建立一个每日运行的定时任务.

#!/bin/bash

bup index /var/www/html 
bup save -r [email protected]: -n techarena51 /var/www/html 

BUP 并不完美, 但它的确能够很好地完成任务. 我当然非常愿意看到这个项目的进一步开发, 希望以后能够增加远程恢复的功能.

你也许喜欢阅读这篇——使用inotify-tools实时文件同步.


via: http://techarena51.com/index.php/using-git-backup-website-files-on-linux/

作者:Leo G 译者:wangjiezhe 校对:Caroline

本文由 LCTT 原创翻译,Linux中国 荣誉推出

之前我们发了一些教程让你熟悉Git基础在团队合作环境中使用Git.我们讨论的这些Git命令足够让一个开发者在Git的世界里生存下去。在这篇教程里,我们试着探索如何高效地管理你的时间以及如何充分利用Git提供的特性。

注意:这里介绍的命令中有的包含方括号(例如:git add -p [file\_name])。在这些例子中,你应该用你自己的数字、标识符等替代方括号里的内容,并且去掉方括号。

1. Git自动补全

如果你在命令行环境中运行Git命令,每次都手动地逐个输入命令是一件很无聊的事。为此,你可以花几分钟时间配置一下Git命令的自动补全功能。

在*nix系统运行下列命令下载自动补全脚本:

cd ~
curl https://raw.github.com/git/git/master/contrib/completion/git-completion.bash -o ~/.git-completion.bash

然后,添加下面的行到你的~/.bash\_profile文件:

if [ -f ~/.git-completion.bash ]; then
    . ~/.git-completion.bash
fi

尽管我之前已经提到过,但我还是想再强调一下:如果你想使用完整的Git特性,你绝bi应该切换到命令行环境。

2. 在Git中忽略文件

你是不是对出现在你Git库里面的编译生成文件(比如.pyc)感到很无语?或者你是不是很厌恶不小心将他们添加到了Git?直接看这里,这里有一个方法可以让你告诉Git忽略所有这些文件和目录。只需要创建一个名字为.gitignore的文件,里面列出你不想要Git跟踪的文件和目录。可以用感叹号(!)列出例外情况。

*.pyc
*.exe
my_db_config/

!main.pyc

3. 谁动了我的代码?

当事情出了乱子时立马责怪别人这是人类的天性。如果你的服务器程序不能正常工作了,要找出罪魁祸首是非常简单的--只需要执行git blame。这个命令告诉你文件里的每一行的作者是谁,最后改动那一行的提交,以及提交的时间戳。

git blame [file_name]

git blame demonstration

在下面的截图里,你可以看到在一个更大的库里这个命令的输出是什么样的:

git blame on the ATutor repository

4. 查看库的历史

在之前的教程里,我们已经看过了如何使用git log命令。不管怎样,有3个选项你应该知道。

  • --oneline - 压缩每次的提交信息,只保留一个缩减的Hash值和说明文字,然后把这些都展示在一行里。
  • --graph - 这个选项将在左边画出一个文字界面的提交历史图。如果你只有一个分支,用这个选项查看历史时是没什么意义的。
  • --all - 显示所有分支历史。

这是这3个选项合起来使用的效果:

Use of git log with all, graph and oneline

5. 不要丢失对某个提交的跟踪

假设你提交了一些不需要的东西,然后你进行了hard重置回到之前的状态。后来,你发现在这个过程中你丢失了其他一些重要的信息,你想要把这些信息找回来,或者至少可以查看一下这些信息。这就需要git reflog帮忙。

简单的git log只能告诉你最近的提交,这个提交的父提交,父提交的父提交,等等。但是git reflog是一个HEAD指向的提交的列表。记住,这个列表依赖于你自己的本地操作环境,它不是库的一部分,也不包含在push或者merge中。

如果执行git log命令,可以看到提交历史,这是我的库的一部分:

Project history

但是,git reflog命令显示了一个被我用hard重置丢掉的提交(b1b0ee9-HEAD@{4}).

Git reflog

6. 暂存文件的一部分更改以便进行一次提交

通常依据特性来提交是一个好的实践方法,意思是说,每一个提交都只添加一个特性或者修复一个bug。想一下如果你一次修复了两个bug或者添加了两个特性但是都还没有逐个提交该怎么办。这种场景下,你可以将他们一起提交。但是有一个更好的办法:单独暂存这些文件,然后分开提交。

让我们假设你对一个文件做了多个更改,然后想让这些更改分开提交。这时,我们用带-p的添加命令。

git add -p [file_name]

我们来试试这种用法。我添加了3个新行到file\_name,但是我只想让第1行和第3行出现在我的提交里。让我们看看git diff的输出是什么样的。

Changes in repo

然后,我们看看带-p选项的add命令会发生什么。

Running add with -p

看起来Git认为所有的更改都是同一个目的的一部分,所以把他们分组到同一个块里。这时,你可以:

  • 输入 y 暂存块
  • 输入 n 不暂存块
  • 输入 e 手动编辑块
  • 输入 d 退出或者跳转到下一个文件
  • 输入 s 分割块

在我们这个例子中,我们想把这个块分割成更小的部分,然后选择其中一些忽略另外一些。

Adding all hunks

如你所见,我们已经逐个添加了第1和第3行,忽略了第2行。你可以看到库的状态并且进行一次提交。

Repository after selectively adding a file

7. 合并多个提交

为了进行核查或者发起一个合并请求(这经常发生在开源项目里),对代码进行了修改提交。但在最后代码被接受之前,你也许会需要修改你的代码。于是你修改代码,但是下一次核查的时候又一次需要进行修改。不知不觉中,你就已经有了好几个提交。理论上你应该用rebase命令把他们合并起来。

git rebase -i HEAD~[number_of_commits]

如果你想合并最后的两次提交,你应该运行下面的命令。

git rebase -i HEAD~2

一旦你运行这个命令,你将进入一个交互式界面,它将询问你想要合并哪些提交。你pick(拣选)最近的提交然后squash(合并)旧的提交。

Git squash interactive

接着你应该提供一个对新提交的说明。这个过程会重写你的提交历史。

Adding a commit message

8. 储藏没有提交的更改

假设你正在修复一个bug或者添加一个特性,突然你被要求展示一下你的工作成果。你现在的工作还没有完成,不够进行一次提交。这时,git stash命令可以用来急救一下。Stash命令跟踪你所有的更改,然后把他们储藏起来以便以后使用。命令如下-

git stash

可以多次储藏更改,查看储藏列表,你可以运行下面的命令:

git stash list

Stash list

如果你想取消储藏,覆盖当前的更改,你可以通过下面的命令使用储藏:

git stash apply

在最后的这个截图里,你可以看到每个储藏都有一个标识符,是一个唯一的数字(尽管在这里我们只有一个储藏)。如果你想使用某个储藏,你在apply命令后面加上这个唯一的标识符:

git stash apply stash@{2}

After un-stashing changes

9. 检查丢失的提交

尽管reflog是一种检查丢失提交的方法,大型的库里却不太实用。这个时候,应该用fsck(文件系统检查)命令。

git fsck --lost-found

Git fsck results

这里你可以看到一个丢失的提交。你可以通过git show [commit\_hash] 查看提交的更改或者通过运行git merge [commit\_hash]命令进行恢复。

git fsck跟reflog命令相比有一个优点。假设你删除了一个远程分支,然后clone了这个库。用fsck命令你可以找到并且恢复这个删除的远程分支。

10. 最佳选择

之前我已经存记下了那些最优雅的Git命令。但是目前为止,cherry-pick命令是我最喜欢的Git命令,因为它直白的名字和实用的功能!

最简单的情况下,cherry-pick从另一个分支里选出单独的一个提交,然后合并到当前分支。如果你正并行工作在两个或者更多的分支上,你也许会发现一个存在于所有分支上的bug。如果你解决了一个分支上的这个bug,你可以拣选这个对应的提交应用到其他分支上,而不会弄乱其他文件或者提交。

让我们来考虑一个可以使用这个命令的场景。我有两个分支,我想拣选b20fd14: Cleaned junk这个提交到另一个分支上。

Before cherry pick

我切换到想要应用这个拣选出来的提交的分支,然后运行下面的命令:

git cherry-pick [commit_hash]

After cherry pick

尽管这次我们很干净的用了cherry-pick命令,但你应该知道这个命令经常会引起冲突,所以请小心使用。

总结

到了这里,我们结束了这个能使你Git能力提升一个级别的列表。Git是最好的版本控制器,它能完成你能想象到的任何事情。所以,经常试着用Git挑战你自己。一不小心你就会学到很多新东西。


via: http://www.sitepoint.com/10-tips-git-next-level/

译者:love\_daisy\_love 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

Git 2.0.2如今已正式发布。这是一个免费和开源的分布式版本控制系统,因其处理速度和效率的优势,它可以处理大大小小各种项目。

新的Git 2.0.x分支保持着带来大量更新的传统,它整合了大量的改变和修正。这个最新的更新只是维护版,但是它的功能特性的确有一些有趣的修改。

根据开发者的描述:"git submodule sync(git子模块的同步)"的文档中提到的子命令可以使用"--recursive"(递归)的选项;在.gitignore中跟踪引用反斜杠的空格的处理不当已经被纠正;对"git repack"命令的更新,将不再错误地复制那些被.keep标签标记的pack目录下的对象。

还有,"git clone -b brefs/tags/bar"不再认为git遵循一个单一的tag,尽管它是一个分支的名称;"%G(G后面没有跟任何东西)"是一个无效的漂亮的格式说明符,现在的解析器不再对它进行解析;用于避免增加相同替代对象的存储的代码经过了两次修正,而且其余的几个修正也已经完成。

想要查看完整的改变列表,查看changelog

下载Git 2.0.2:


via: http://news.softpedia.com/news/Git-2-0-2-Version-Control-System-Now-Available-for-Download-451147.shtml

译者:su-kaiyao 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

Git 1.9.3,是一种自由和开放源码的分布式控制版本系统,该设计用于快速有效地处理从小到非常大的项目,现在已经可以提供下载了。

新的Git 1.9.x系列继续保持着大量发布的传统,包含了大量的变动和修复。最新版本系列比我们预期稍微小了一点,但的确做了一些有趣的变化。如果你在使用Git,你也许该考虑升级到最新版本的。

根据开发者所说,“git p4”在处理二进制文件时受损是由于1.9版本的一些改变,但是这已经被修复了。在shell提示符脚本(在contrib目录/下),使用PROMPT\_COMMAND界面时,显示分支名称$PS时不再使用不安全的构造,“git rebase”也不再使用POSIX shell中的结构。

此外,一些在Unicode6.3中定义的代码点的零宽度问题的已经得到修复,在一些不能在FreeBSD中运行的shell结构的测试,也都已经得到修复了。

关于更改的完整列表,请查看更新日志

下载Git 1.9.3地址


via: http://news.softpedia.com/news/Git-1-9-3-Version-Control-System-Officially-Released-441600.shtml

译者:disylee 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出