debug1: No more authentication methods to try.

git@codeup.aliyun.com: Permission denied (publickey).

已深度思考(用时7秒)

用户现在遇到的问题是Git克隆阿里云CodeUp仓库时出现“debug1: No more authentication methods to try.”和“Permission denied (publickey)”错误。首先，我需要回忆之前的对话，用户之前已经问过类似的问题，当时提供了很多排查步骤，但现在用户给出的错误信息更具体，提到了“没有更多认证方法可尝试”，这说明SSH客户端已经尝试了所有可能的认证方法，但都失败了。

首先，我需要明确这个错误的原因。通常，当SSH连接时，客户端会尝试使用配置的密钥进行认证，如果没有找到合适的密钥或者密钥不被服务器接受，就会出现这个错误。结合之前的对话，用户可能已经尝试过生成密钥、添加公钥到CodeUp、加载私钥等步骤，但可能还有遗漏的地方。

接下来，我需要分析可能的排查点。根据错误信息，“No more authentication methods to try”意味着SSH客户端没有可用的认证方法了。可能的原因包括：本地没有可用的SSH密钥、密钥未正确加载到ssh-agent、密钥权限不正确、SSH配置文件未正确指定密钥、服务器未接受提供的密钥等。

然后，我需要回顾之前的回答，确保这次的回答更聚焦于这个具体的错误信息。之前的回答提到了检查密钥是否存在、添加公钥、加载私钥、权限设置、SSH配置文件、网络测试等，现在需要将这些步骤更针对性地结合起来，特别是针对“没有更多认证方法”这一点。

另外，用户可能没有正确配置SSH配置文件，导致SSH客户端没有使用正确的密钥去连接CodeUp。或者，虽然生成了密钥，但没有将私钥添加到ssh-agent，导致客户端无法找到密钥。还有一种可能是，用户有多个密钥，但SSH客户端没有尝试正确的那个，这时候需要在~/.ssh/config中明确指定。

还要注意，用户可能在生成密钥时使用了不同的算法或文件名，比如使用了id_rsa而不是id_ed25519，或者在添加公钥到CodeUp时复制错了内容。此外，私钥文件的权限必须是600，.ssh目录权限是700，否则SSH会忽略该密钥。

另外，测试SSH连接时使用ssh -T git@codeup.aliyun.com -v可以查看详细的调试信息，显示客户端尝试了哪些密钥，服务器接受了哪些，这对排查问题非常有帮助。用户可能需要执行这个命令来查看具体尝试的密钥和失败原因。

总结下来，解决步骤应该包括：1. 确认本地有SSH密钥；2. 确保公钥已正确添加到CodeUp；3. 检查私钥是否加载到ssh-agent；4. 验证私钥权限和.ssh目录权限；5. 配置~/.ssh/config指定CodeUp的密钥；6. 使用-v参数调试SSH连接，查看详细过程；7. 备选方案使用HTTPS克隆。

需要确保回答清晰，步骤明确，特别是针对“没有更多认证方法”这一关键点，强调检查是否有可用密钥、是否正确加载、配置是否正确，以及如何通过调试日志定位问题。

debug1: No more authentication methods to try.结合 Permission denied (publickey)表明：SSH 客户端已尝试所有可能的认证方法（主要是公钥），但均被服务器拒绝，最终导致认证失败。这是 SSH 公钥认证失败的典型表现，核心原因是客户端未提供服务器接受的 SSH 公钥，或提供的密钥无效/未加载。

一、核心原因定位

通过 ssh -T git@codeup.aliyun.com -v命令（加 -v查看详细调试日志），重点关注以下输出：

debug1: Authentications that can continue: publickey

debug1: Next authentication method: publickey

debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:xxxxxx explicit

debug1: Authentications that can continue: publickey

debug1: Trying private key: /home/user/.ssh/id_dsa

debug1: Trying private key: /home/user/.ssh/id_ecdsa

debug1: Trying private key: /home/user/.ssh/id_ed25519

debug1: No more authentication methods to try.

git@codeup.aliyun.com: Permission denied (publickey).

日志中 Offering public key会显示客户端尝试的密钥路径（如 id_rsa、id_ed25519）。

若所有密钥均显示 Authentications that can continue: publickey后无 Server accepts key，说明服务器未接受任何提供的密钥。

二、分步解决（按优先级排序）

1. 确认客户端有可用 SSH 密钥，且公钥已添加到 CodeUp

这是最常见原因：客户端未生成密钥，或生成的密钥未添加到 CodeUp 的「SSH 公钥」列表。

检查本地密钥：

ls -la ~/.ssh # 查看是否有 id_rsa.pub/id_ed25519.pub 等公钥文件

若无密钥：执行 ssh-keygen -t ed25519 -C “你的邮箱”生成（一路回车默认即可）。

复制公钥内容（以 Ed25519 为例）：

cat ~/.ssh/id_ed25519.pub # 输出类似：ssh-ed25519 AAAAB3NzaC1yc2E… 邮箱

添加公钥到 CodeUp：

登录 阿里云 CodeUp→ 右上角头像 → 个人设置​ → SSH 公钥​ → 添加公钥，粘贴公钥内容并保存。

2. 确保私钥已加载到 ssh-agent（关键！）

SSH 客户端默认不会主动加载私钥，需通过 ssh-agent管理（尤其当私钥有密码或存在多个密钥时）。

启动 ssh-agent 并加载私钥：

eval “$(ssh-agent -s)” # 启动 agent（输出 Agent pid xxxx 表示成功）

ssh-add ~/.ssh/id_ed25519 # 加载私钥（替换为你的私钥文件名，如 id_rsa）

若提示 Identity added，说明加载成功；

若提示 Could not open a connection to your authentication agent，先执行 eval “$(ssh-agent -s)”再重试。

验证已加载密钥：

ssh-add -l # 列出 agent 中加载的密钥指纹，应能看到你的私钥

3. 修复私钥权限（SSH 安全检查）

SSH 严格要求私钥文件权限为 600（仅所有者可读写），.ssh目录权限为 700，否则会拒绝使用该密钥。

chmod 700 ~/.ssh # .ssh 目录权限（必须）

chmod 600 ~/.ssh/id_ed25519 # 私钥权限（替换为你的私钥文件名）

chmod 644 ~/.ssh/id_ed25519.pub # 公钥权限（可选，不影响认证）

4. 配置 SSH 配置文件（指定 CodeUp 专用密钥）

若你有多个 SSH 密钥（如 GitHub、GitLab 各一个），需在 ~/.ssh/config中明确指定 CodeUp 使用的密钥，避免客户端尝试无关密钥。

创建/编辑配置文件：

vim ~/.ssh/config

添加以下内容（根据实际密钥路径修改）：

阿里云 CodeUp 专用配置

Host codeup.aliyun.com

HostName codeup.aliyun.com # 服务器地址

User git # 固定用户名为 git

IdentityFile ~/.ssh/id_ed25519 # 你的私钥路径（绝对路径更佳，如 /home/user/.ssh/id_ed25519）

IdentitiesOnly yes # 仅使用指定密钥，不尝试其他密钥

PreferredAuthentications publickey # 优先使用公钥认证

5. 验证 SSH 连接（关键测试）

执行以下命令测试认证是否成功，必须看到欢迎信息：

ssh -T git@codeup.aliyun.com

成功提示：Welcome to Codeup, <你的阿里云账号名>!（说明认证通过）。

失败提示：若仍提示 Permission denied，执行 ssh -T git@codeup.aliyun.com -v查看详细日志，重点关注：

客户端尝试了哪些密钥（Offering public key: …）；

服务器是否接受密钥（Server accepts key: …）。

6. 排查网络与仓库权限

网络连通性：确保服务器能访问 CodeUp 的 SSH 端口（22）：

telnet codeup.aliyun.com 22 # 成功会显示 “SSH-2.0-OpenSSH_xxx”

若端口不通：检查服务器安全组（阿里云 ECS → 安全组 → 放行 22 端口）。

仓库权限：确认你要克隆的仓库是公开仓库，或你是仓库成员（联系管理员添加「开发者」及以上权限）。

三、备选方案：用 HTTPS 协议克隆（临时解决）

若 SSH 仍有问题，可临时用 HTTPS 协议克隆（需输入 CodeUp 账号密码或个人访问令牌）：

生成个人访问令牌（推荐，比密码安全）：

登录 CodeUp → 个人设置 → 访问令牌​ → 创建令牌（勾选 repo权限）。

用令牌克隆：

git clone https://codeup.aliyun.com/62a863ad487c507f6270c/adbd/test-android.git

提示输入用户名时填阿里云账号，密码填生成的个人访问令牌。

四、终极调试：通过 SSH 日志定位问题

执行 ssh -T git@codeup.aliyun.com -vvv（加 -vvv获取最详细日志），重点关注：

debug1: Offering public key: …：客户端尝试的密钥路径是否正确？

debug1: Server accepts key: …：服务器是否接受该密钥？（若没有这行，说明密钥未被接受）

debug1: No more authentication methods to try：确认所有密钥均已尝试但仍失败。

总结

No more authentication methods to try的核心是SSH 客户端未找到服务器接受的密钥。按以下顺序排查：

本地是否有密钥 → 2. 公钥是否添加到 CodeUp → 3. 私钥是否加载到 ssh-agent → 4. 私钥权限是否正确 → 5. SSH 配置是否指定密钥 → 6. 测试连接并查看日志。

完成后，重新执行 git clone git@codeup.aliyun.com:62a863ad487c500c27f6270c/rpa/wxhb-android.git即可成功。

debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:9zXtSmeY2pFh80g/XvNe3ufzQm4eFZs0hONLqCI/VGM

debug1: Authentications that can continue: publickey

debug1: Trying private key: /root/.ssh/id_ecdsa

debug1: Trying private key: /root/.ssh/id_ecdsa_sk

debug1: Trying private key: /root/.ssh/id_ed25519

debug1: Trying private key: /root/.ssh/id_ed25519_sk

debug1: Trying private key: /root/.ssh/id_xmss

debug1: Trying private key: /root/.ssh/id_dsa

debug1: No more authentication methods to try.

git@codeup.aliyun.com: Permission denied (publickey).

已深度思考(用时8秒)

用户现在遇到的SSH认证问题是：客户端尝试了多个私钥（包括id_rsa、id_ecdsa、id_ed25519等），但都被服务器拒绝，最终提示“Permission denied (publickey)”。根据之前的对话，用户已经尝试过生成密钥、添加公钥到CodeUp、加载私钥到ssh-agent等操作，但问题依然存在。现在需要从提供的调试日志中分析问题所在。

首先，仔细看调试日志：“debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:9zXtSmeY2pFh80g/XvNe3ufzQm4eFZs0hONLqCI/VGM”，这说明客户端尝试了/root/.ssh/id_rsa这个公钥，但服务器没有接受（因为后面只显示“Authentications that can continue: publickey”，没有“Server accepts key”）。接着客户端尝试了其他私钥（id_ecdsa、id_ed25519等），但都没有成功，最终“No more authentication methods to try”。

核心问题在于：客户端提供的公钥（尤其是id_rsa.pub）没有被阿里云CodeUp服务器接受。可能的原因有几个：1. 用户添加到CodeUp的公钥不是当前客户端正在使用的这个id_rsa.pub；2. 公钥添加到了错误的CodeUp账户；3. 公钥内容复制有误（比如多了空格、换行，或者不完整）；4. 服务器端对该公钥的权限设置有问题（比如仓库未授权）。

接下来，需要引导用户确认几个关键点：首先，检查/root/.ssh/id_rsa.pub的内容，确保和添加到CodeUp的公钥完全一致；其次，确认添加公钥的CodeUp账户是否是当前克隆仓库的账户（比如是否有多个阿里云账户）；另外，可能用户之前生成过多个密钥，而添加到CodeUp的是另一个密钥（比如id_ed25519.pub），但客户端当前尝试的是id_rsa，所以服务器不接受。

另外，日志中显示客户端尝试了多个密钥，包括id_rsa、id_ecdsa、id_ed25519等，但用户可能只在CodeUp添加了其中一个（比如id_ed25519.pub），而客户端优先尝试了id_rsa（因为ssh-agent中可能加载了多个，或者配置中没有指定IdentityFile），导致服务器不接受id_rsa的公钥。这时候需要通过SSH配置文件指定只使用添加到CodeUp的那个密钥。

还有可能是权限问题，虽然用户之前可能改过权限，但需要再次确认/root/.ssh目录权限是700，私钥id_rsa权限是600，公钥权限644。另外，root用户的.ssh目录可能存在权限问题，或者SELinux/AppArmor的限制（不过这种情况较少见）。

总结下来，解决步骤应该是：1. 确认客户端当前使用的公钥（id_rsa.pub）是否已添加到CodeUp；2. 若添加了其他公钥（如id_ed25519.pub），则配置SSH只使用该公钥；3. 检查公钥内容是否完全一致，无多余字符；4. 确认CodeUp账户权限；5. 重新测试连接并查看详细日志。

从你提供的 ssh -T git@codeup.aliyun.com -v调试日志来看，核心问题是：客户端尝试了多个 SSH 私钥（包括 /root/.ssh/id_rsa、id_ecdsa、id_ed25519等），但服务器均未接受这些密钥，最终导致认证失败。以下是具体分析和解决步骤：

一、日志关键信息解读

debug1: Offering public key: /root/.ssh/id_rsa RSA SHA256:9zXtSmeY2pFh80g/XvNe3ufzQm4eFZs0hONLqCI/VGM

debug1: Authentications that can continue: publickey

debug1: Trying private key: /root/.ssh/id_ecdsa

debug1: Trying private key: /root/.ssh/id_ecdsa_sk

debug1: Trying private key: /root/.ssh/id_ed25519

debug1: Trying private key: /root/.ssh/id_ed25519_sk

debug1: Trying private key: /root/.ssh/id_xmss

debug1: Trying private key: /root/.ssh/id_dsa

debug1: No more authentication methods to try.

git@codeup.aliyun.com: Permission denied (publickey).

Offering public key: /root/.ssh/id_rsa：客户端首先尝试使用 /root/.ssh/id_rsa私钥对应的公钥进行认证，但服务器未接受（无 Server accepts key提示）。

后续尝试其他密钥：客户端依次尝试了 id_ecdsa、id_ed25519等所有本地私钥，但均被服务器拒绝。

最终失败：所有密钥尝试完毕，服务器仍未接受，返回 Permission denied。

二、核心原因定位

最可能的原因：你添加到阿里云 CodeUp 的公钥，与客户端当前尝试的私钥不匹配（即服务器没有你正在使用的这些私钥对应的公钥）。

例如：

你可能在 CodeUp 添加的是 id_ed25519.pub公钥，但客户端优先尝试了 id_rsa私钥（因 ssh-agent加载顺序或配置问题），而 id_rsa.pub未添加到 CodeUp；

或你添加的公钥内容有误（如复制时遗漏字符、多了空格），导致服务器无法识别；

或你添加公钥时用的是 A 阿里云账户，但当前克隆仓库用的是 B 账户（无权限）。

三、分步解决步骤

Step 1：确认「客户端使用的密钥」与「CodeUp 添加的公钥」是否匹配

这是最关键的一步！必须确保 客户端正在尝试的私钥对应的公钥，已添加到 CodeUp。

① 查看客户端当前尝试的所有密钥​

从日志可知，客户端尝试了以下私钥（按优先级排序）：

/root/.ssh/id_rsa→ id_ecdsa→ id_ed25519→ id_xmss→ id_dsa

② 检查这些私钥对应的公钥是否已添加到 CodeUp​

假设你希望使用 id_ed25519密钥（推荐，更安全），则需确保 id_ed25519.pub已添加到 CodeUp：

1. 查看 id_ed25519.pub 内容（复制此内容，用于对比 CodeUp 添加的公钥）

cat ~/.ssh/id_ed25519.pub

输出示例：ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKZxxxxxx… 你的邮箱

2. 登录 CodeUp 控制台（https://codeup.aliyun.com/）→ 个人设置 → SSH 公钥

3. 检查已添加的公钥中，是否有与上述 id_ed25519.pub 完全一致的内容

若未添加：将 id_ed25519.pub内容复制到 CodeUp 并添加。

若添加的是其他公钥（如 id_rsa.pub）：确保 id_rsa.pub内容与 CodeUp 添加的一致，或通过 SSH 配置强制使用 id_ed25519。

Step 2：通过 SSH 配置强制使用「已添加到 CodeUp 的密钥」

若你有多个密钥（如同时有 id_rsa和 id_ed25519），需在 ~/.ssh/config中明确指定 CodeUp 只使用已添加到 CodeUp 的那个密钥，避免客户端尝试无关密钥。

① 编辑 SSH 配置文件​

vim ~/.ssh/config

② 添加 CodeUp 专用配置（以 id_ed25519为例）​

阿里云 CodeUp 专用配置（替换为你的密钥路径和文件名）

Host codeup.aliyun.com

HostName codeup.aliyun.com # 服务器地址（固定）

User git # 固定用户名为 git

IdentityFile ~/.ssh/id_ed25519 # 仅使用 id_ed25519 私钥（确保此公钥已添加到 CodeUp）

IdentitiesOnly yes # 仅用指定密钥，不尝试其他密钥

PreferredAuthentications publickey # 优先公钥认证

③ 保存后测试连接​

ssh -T git@codeup.aliyun.com

若成功，会显示 Welcome to Codeup, <你的阿里云账号名>!。

Step 3：修复「公钥内容不一致」或「账户权限」问题

① 确保公钥内容完全一致​

复制公钥时避免多余字符（如换行符、空格），建议用 cat命令直接输出并复制：

cat ~/.ssh/id_ed25519.pub | xclip -selection clipboard # Linux 复制到剪贴板（需安装 xclip）

或手动选中输出内容复制（注意不要复制末尾的邮箱别名外的多余字符）

② 确认 CodeUp 账户权限​

确保你添加公钥的阿里云账户，有权限访问目标仓库（仓库是公开仓库，或你是仓库成员/管理员）。

若仓库属于某个组织，需联系组织管理员将你的账户添加为成员（角色至少「开发者」）。

Step 4：验证私钥权限与 ssh-agent 加载

即使配置了 IdentityFile，仍需确保私钥权限正确且已加载到 ssh-agent（尤其当私钥有密码时）：

① 修复私钥权限​

chmod 700 ~/.ssh # .ssh 目录权限（必须）

chmod 600 ~/.ssh/id_ed25519 # 私钥权限（替换为你的私钥文件名）

② 加载私钥到 ssh-agent​

eval “$(ssh-agent -s)” # 启动 ssh-agent（输出 Agent pid xxxx 表示成功）

ssh-add ~/.ssh/id_ed25519 # 加载私钥（若提示输入密码，输入生成密钥时设置的密码）

ssh-add -l # 验证是否加载成功（应显示密钥指纹）

Step 5：终极测试与日志分析

若以上步骤无效，执行 最详细日志​ 定位问题：

ssh -T git@codeup.aliyun.com -vvv # 加 -vvv 获取所有调试信息

重点关注以下输出：

debug1: Offering public key: …：确认客户端是否使用了你在 config中指定的密钥（如 id_ed25519）。

debug1: Server accepts key: …：若出现此行，说明服务器接受了密钥（认证成功）；若没有，说明密钥未被接受（回到 Step 1 检查公钥是否添加正确）。

四、备选方案：用 HTTPS 协议临时克隆（绕过 SSH）

若 SSH 问题暂时无法解决，可先用 HTTPS 协议克隆（需输入 CodeUp 账号密码或个人访问令牌）：

生成个人访问令牌（推荐，比密码安全）：

登录 CodeUp → 个人设置 → 访问令牌​ → 创建令牌（勾选 repo权限）。

HTTPS 克隆仓库：

git clone https://codeup.aliyun.com/62a863ad487c57f6270c/abcd/test-android.git

提示输入用户名时填阿里云账号，密码填生成的个人访问令牌。

总结

当前问题的核心是 客户端尝试的密钥与 CodeUp 添加的公钥不匹配。按以下顺序排查：

确认 IdentityFile指定的私钥（如 id_ed25519）对应的公钥已添加到 CodeUp；

通过 ~/.ssh/config强制 SSH 只使用该密钥；

检查公钥内容是否完全一致、账户权限是否正确；

修复私钥权限并加载到 ssh-agent。

完成后，重新执行 git clone git@codeup.aliyun.com:62a8687c500c27f6270c/abcd/test-android.git即可成功。

问题描述¶

提交git记录前需要先设置用户名和邮箱，最常用的方式就是全局设置

$ git config --global user.name xxx
$ git config --global user.email xxx
# 查看
$ git config -l

最近想要在服务器上进行版本管理，不方便全局设置，可以在项目路径下进行本地设置

方式一¶

进入项目路径，执行如下命令

$ git config --local user.name xxx
$ git config --local user.email xxx
# 查询
$ git config --local -l

方式二¶

直接在.git/config配置文件中设置

[user]
    name = xxx
    email = xxx

最近在开发一个新应用，有一天在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文件本身。