最近在开发一个新应用，有一天在gitlab上clone代码的时候发现我的应用竟然有170+M，明明是一个全新的应用，代码都没有几行呢，为什么会有这么大呢？

后来经过了解Git的原理，解决了这个问题，把相关内容记录下来。分享一下。

Why

我的一个新应用竟然要170+M，这是打死我我也不会信的，于是就开始分析为什么会这么大。

step 1. 把代码拉到本地

git clone git@github.com:hollischuang/Architecture-Evolution.git

只是用这个地址举例，实际并不是这个项目。

step 2. 查看哪个文件占用的空间比较大

$cd Architecture-Evolution
$du -d 1 -h
 174M   ./.git
 264K   ./test
 96K    .

于是，发现是.git目录自己就占用了174M，了解Git的人都知道，.git目录是git自己生成的，记录了git仓库的相关信息的。看到这里其实并不难知道原因。

Git 维护着一个微型的文件系统，其中的文件也被称作数据对象。所有的数据对象均存储于项目下面的 .git/objects中。

经过我的验证，确实是.git/objects这个文件夹中的文件占了磁盘上174M的空间。

也就是说，只要我有一次将一个大文件误提交了，那么即使我后面把它删除了，但是，实际上在.git中，这个文件还是存在的，虽然我们可能再也不需要他了，但是他还在那里默默的存在着。。。

Git与大部分版本控制系统的差别是很大的，比如Subversion、CVS、Perforce、Mercurial 等等，使用的是“增量文件系统” （Delta Storage systems）, 就是说它们存储每次提交(commit)之间的差异。Git正好与之相反，它会把你的每次提交的文件的全部内容（snapshot）都会记录下来。这会是在使用Git时的一个很重要的理念。

也就是说，如果我又一次把一个大文件务提交到git仓库中了，那么，下次提交时，即使你只改动了某个文件的一行内容，Git 也会生成一个全新的对象来存储新的文件内容。

因为以上两个特性，我回想起我的一次手残行为：
刚刚创建一个应用之后，我快速的写完代码，编译，运行，发现没啥问题之后，我准备先把他发布掉，于是我开始创建git仓库，并尝试把代码提交上去，这时我并没有创建.gitignore文件，我直接git add . git commit -m 'init'git push一气呵成的执行了熟悉的操作。

相信聪明的人已经发现了，逗比啊，我在编译代码之后，会有很多jar被我down到target目录下。我直接git add.把target下面的jar包，war包等这些也直接提交了。。。虽然后面我意识到，并且删除了这些文件，然后再次提交，但是由于刚我们说过的原因，这些文件依然占用着我的空间。。。

更多关于git的原理内容参见：Git 内部原理

How

问题已经定位到了，接下来就是要解决问题了。如果对git的原理及命令了解的比较多的话，这个问题还是比较好解决的，由于当时博主并不十分了解git的原理，所以做了一些知识储备之后才开始动手的。（Git 之术与道 — 对象、为什么你的 Git 仓库变得如此臃肿）

Step 1 查看哪些历史提交过文件占用空间较大

使用以下命令可以查看占用空间最多的五个文件：

git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5 | awk '{print$1}')"

rev-list命令用来列出Git仓库中的提交，我们用它来列出所有提交中涉及的文件名及其ID。 该命令可以指定只显示某个引用（或分支）的上下游的提交。

--objects：列出该提交涉及的所有文件ID。

--all：所有分支的提交，相当于指定了位于/refs下的所有引用。

verify-pack命令用于显示已打包的内容。

step 2. 重写commit，删除大文件

使用以下命令，删除历史提交过的大文件：

git filter-branch --force --index-filter 'git rm -rf --cached --ignore-unmatch big-file.jar' --prune-empty --tag-name-filter cat -- --all

上面脚本中的big-file.jar请换成你第一步查出的大文件名，或者这里直接写一个目录。

filter-branch命令可以用来重写Git仓库中的提交

--index-filter参数用来指定一条Bash命令，然后Git会检出（checkout）所有的提交， 执行该命令，然后重新提交。

–all参数表示我们需要重写所有分支（或引用）。

在重写提交的过程中，会有以下日志输出:

Rewrite 6cdbb293d453ced07e6a07e0aa6e580e6a5538f4 (266/266)
# Ref 'refs/heads/master' was rewritten

如果显示 xxxxx unchanged, 说明repo里没有找到该文件, 请检查路径和文件名是否正确，重复上面的脚本，把所有你想删除的文件都删掉。

step 3. 推送修改后的repo

以强制覆盖的方式推送你的repo, 命令如下:

git push origin master --force

step 4. 清理和回收空间

虽然上面我们已经删除了文件, 但是我们的repo里面仍然保留了这些objects, 等待垃圾回收(GC), 所以我们要用命令彻底清除它, 并收回空间，命令如下:

rm -rf .git/refs/original/

git reflog expire --expire=now --all

git gc --prune=now

至此，我们已经彻底的删除了我们不想要的文件。

来源：http://www.hollischuang.com/archives/1708

由于某种原因ssh的端口号由原来的22调整为92573，因此在使用git仓库时，地址也相应进行变更，详细说明如下：

1、克隆仓库

由原来的克隆命令

git clone git@192.168.4.46:test.git

变更为

git clone ssh://git@192.168.4.46:92573/test.git

2、修改仓库url地址

如果之前已经克隆过仓库，则只需修改url地址即可。
编辑.git/config文件
将url地址由git@192.168.4.46:test.git 修改为 ssh://git@192.168.4.46:92573/test.git
保存文件
git pull 同步即可。

3、改动的地方

增加了ssh://
增加了端口号
把用户名前面的冒号改成了斜杠(/)

Git Protocol

A guide for programming within version control.

Maintain a Repo

• Avoid including files in source control that are specific to your development machine or process.
• Delete local and remote feature branches after merging.
• Perform work in a feature branch.
• Rebase frequently to incorporate upstream changes.
• Use a pull request for code reviews.

Write a Feature

Create a local feature branch based off master.

git checkout master
git pull
git checkout -b <branch-name>

Rebase frequently to incorporate upstream changes.

git fetch origin
git rebase origin/master

Resolve conflicts. When feature is complete and tests pass, stage the changes.

git add --all

When you’ve staged the changes, commit them.

git status
git commit --verbose

Write a good commit message. Example format:

Present-tense summary under 50 characters

* More information about commit (under 72 characters).
* More information about commit (under 72 characters).

http://project.management-system.com/ticket/123

If you’ve created more than one commit, use a rebase to squash them into cohesive commits with good messages:

git rebase -i origin/master

Share your branch.

git push origin <branch-name>

Submit a GitHub pull request.

Ask for a code review in the project’s chat room.

Review Code

A team member other than the author reviews the pull request. They follow Code Review guidelines to avoid miscommunication.

They make comments and ask questions directly on lines of code in the GitHub web interface or in the project’s chat room.

For changes which they can make themselves, they check out the branch.

git checkout <branch-name>
./bin/setup
git diff staging/master..HEAD

They make small changes right in the branch, test the feature on their machine, run tests, commit, and push.

When satisfied, they comment on the pull request Ready to merge.

Merge

Rebase interactively. Squash commits like “Fix whitespace” into one or a small number of valuable commit(s). Edit commit messages to reveal intent. Run tests.

git fetch origin
git rebase -i origin/master

Force push your branch. This allows GitHub to automatically close your pull request and mark it as merged when your commit(s) are pushed to master. It also makes it possible to find the pull request that brought in your changes.

git push --force origin <branch-name>

View a list of new commits. View changed files. Merge branch into master.

git log origin/master..<branch-name>
git diff --stat origin/master
git checkout master
git merge <branch-name> --ff-only
git push

Delete your remote feature branch.

git push origin --delete <branch-name>

Delete your local feature branch.

git branch --delete <branch-name>

link: https://github.com/thoughtbot/guides/tree/master/protocol/git

问题：Git仓库中的.gitignore文件失效

解决方案：

曲线救国，在每个clone下来的仓库中手动设置不要检查特定文件的更改情况，命令如下：

git update-index –assume-unchanged PATH

在PATH处输入要忽略的文件。

注：

建立.gitignore文件，写入文件名或目录名，编译器就可以忽略这些文件的修改，例如：

.gitignore .classpath .project bin/

在我的情况里，这些文件一般是载入工程时，Eclipse自动修改的文件，当然还有.gitignore文件本身。