git 命令参考

git rm --cached nohup.out

文件已经tracked了，那么删除它需要--cached

git filter-branch --force --index-filter "git rm --cached --ignore-unmatch \<filename\>"  --prune-empty --tag-name-filter cat -- --all

使用git filter-branch命令来修改Git仓库历史记录的操作

• --force：强制执行操作，即使它可能会导致数据丢失。
• --index-filter git rm --cached --ignore-unmatch <filename>：这是一个用于修改索引（即暂存区）的过滤器。它使用git rm --cached --ignore-unmatch <filename>命令来删除暂存区中的指定文件。
• --prune-empty：删除空的提交记录，这些记录在应用过滤器后没有任何更改的内容。
• --tag-name-filter cat：对标签进行过滤，并保留其内容不变。
• -- --all：双横线（--）之后指定了所有分支的引用，表示要对所有分支执行过滤操作。

通过git filter-branch，使用索引过滤器删除指定文件所有历史记录，在过滤过程中删除空的提交记录。这可改变仓库历史状态，删除指定文件所有轨迹

merge 有两种

• 快速合并
• 三向合并(three-way merge)

To see a list of commits for all the branches in your local repository, you must use the git log command with the --all option.

git checkout可以回溯到之前的一个commit。HEAD 指针将直接指向提交，而不是指向分支。这意味着您将处于 Git（可怕地）称为分离 HEAD 状态的状态，不建议在处于分离 HEAD 状态（即不在分支上）时对存储库进行任何更改。你通常需要在分支上进行提交，因为分支比提交哈希更容易记住和引用，并且因为 Git 被设计为与分支一起使用

git push <shortname> -d <branch_name> 删除远程分支和关联的远程跟踪分支

git branch -d <branch_name> 删除本地分支

在 Git 项目中可能遇到的规则的一个示例是，个人应仅处理自己的主题分支，避免处理其他人的主题分支。这有助于避免合并冲突

git branch -vv -all

git pull实际上是git fetch和git merge的合体

回到上个commit（现在暂时没有commit）

git reset --hard HEAD

想临时获取以前某个版本的代码来运行测试或做实验

git checkout <commit-id>
 
git branch
 
git checkout master(or main or any other branch that is the original one)

git pull --ff-only： 这个命令尝试进行"快进"(fast-forward)合并。如果你的本地分支落后于远程分支，它会更新本地分支到远程分支的最新提交。但如果存在任何本地提交，使得快进合并不可能（也就是说，远程分支和你的本地分支有分叉），此命令会失败。

git pull --rebase： 此命令首先获取远程分支的新更改，然后尝试将你的本地分支上的更改重新应用（或 "rebase"）在远程分支的最新更改之上。这样可以确保提交历史线性，但可能需要解决合并冲突。

merge保留了完整的历史记录和原始的提交顺序，但可能会导致项目历史图变得更加复杂。

rebase通过改变提交的顺序和/或哈希值来整理和线性化项目历史，但并不保留原始的提交历史，并可能导致团队协作中的问题。

以下是一些常见的分支：

• 主分支（Main or Master）: 这是源代码的主分支，通常包含了生产就绪的代码。任何时候从主分支拉出的代码都应该是稳定的、经过测试的，并且可以立即部署到生产环境中。
• 开发分支（Develop）: 如果你的团队遵循Git Flow工作流，那么“develop”分支通常用作集成分支，用于开发者合并他们的功能分支更改。这里的代码是下一个发布周期的代码，当代码达到稳定状态时，它会被合并到主分支。
• 功能分支（Feature branches）: 对于正在开发的每个新功能或改进，团队成员会从主分支或开发分支创建一个新的功能分支。功能分支应该是短期的，并在功能完成后合并回开发分支或主分支，并被删除。
• 修复分支（Hotfix branches）: 这些分支用于快速修复生产中的问题。它们通常从主分支创建，并在修复完成后立即合并回主分支和开发分支。
• 发布分支（Release branches）: 如果你的团队遵循具有预定发布周期的工作流程，那么你可能会有发布分支。这些分支用于准备即将发布的代码版本，允许团队修复bug并完成发布准备工作，而不会干扰对下一个版本的开发工作。
• 支持/维护分支（Support/Maintenance branches）: 对于已经发布并且可能需要长期支持的产品版本，你可能需要从主分支创建一个支持分支。这对于需要维护多个版本（如软件提供商）的情况特别有用。

在 Git 中删除已经提交的 commit，你可以使用以下几种方法，具体取决于你的需求：

使用 git reset:

• 如果你想删除最近的几个提交，可以使用 git reset。例如，如果你想删除最后一个提交，可以使用 git reset --hard HEAD~1。这将把 HEAD 指向前一个提交，且不保留当前提交的更改。请注意，使用 --hard 选项会丢失所有未提交的更改。

使用 git revert:

• 如果你想撤销特定的提交，同时保留对该提交之后的历史记录，可以使用 git revert <commit_hash>。这将创建一个新的提交，该提交撤销指定提交的更改。

交互式 rebase (git rebase -i):

• 如果你想删除或修改旧的提交，可以使用 git rebase -i <commit_hash>^，这里 <commit_hash> 是你想修改的提交的哈希值。在弹出的交互式界面中，你可以选择删除、修改或重新排序提交。

要放弃从 2dd65392b0a790d53c14c3a361c8036f95c04c1b 以后的所有提交（即这个提交之前的所有内容），同时保留你在工作目录中当前所做的修改，你可以使用 git reset 命令，配合 --soft 或 --mixed 选项。这样做会重置你的 HEAD 到指定的提交，但不会影响你当前的工作目录和暂存区。具体步骤如下：

首先，确保你的工作目录是干净的:

• 你可能需要提交或暂存当前的更改，或者使用 git stash 来暂时存储它们。

然后，使用 git reset 命令:

• 使用 git reset --soft 2dd65392b0a790d53c14c3a361c8036f95c04c1b^ 会重置到指定提交的父提交，但保留你的更改在暂存区。
• 使用 git reset --mixed 2dd65392b0a790d53c14c3a361c8036f95c04c1b^ 会重置到指定提交的父提交，并将更改保留在工作目录，但不在暂存区。

这里的 ^ 符号表示指定提交的父提交，这是必要的，因为你想保留 2dd65392b0a790d53c14c3a361c8036f95c04c1b 这个提交。

检查状态:

• 执行 git status 来查看当前的更改。如果你使用了 --soft 选项，更改将出现在暂存区。如果你使用了 --mixed 选项，更改将只在工作目录中。

可选的后续步骤:

• 如果你满意更改，可以再次提交它们。如果你使用了 git stash 来暂时存储更改，请使用 git stash pop 或 git stash apply 来恢复它们。

使用 git reset 命令将 HEAD 重置到一个旧的提交会在你的本地仓库中“删除”这之后的提交，但这些提交实际上并没有被完全删除。它们在 Git 的历史记录中仍然存在，但不再是当前分支的一部分。这意味着在特定情况下，这些提交仍然可以被恢复。

如果你需要，你可以通过以下方式找回这些“删除”的提交：

• 通过 git reflog: git reflog 显示了你的本地仓库的 HEAD 记录。即使 commit 不再在任何分支上，它仍然可以在这里找到。你可以通过检查 git reflog 的输出来找到“删除”提交的哈希值，并使用 git checkout <commit_hash> 或 git branch <new_branch_name> <commit_hash> 来检出或创建一个新分支。

要查看一个特定的 commit 修改了哪些文件，你可以使用 git show 命令，后跟该 commit 的哈希值。这个命令会显示那个 commit 的详细信息，包括它所做的更改（即 diffs）。