我的Git repo有数百GB的数据,比如SQL备份,所以我试图删除旧的,过时的提交,因为它们会使一切变得越来越大.我需要一个快速的解决方案; 越快越好.

除了最新的提交之外,我如何压缩所有提交,而不必在交互式rebase中手动压缩每个提交？具体来说,我不想使用

git rebase -i --root

我的回购

我有这些提交:

A .. B .. C ... ... H .. I .. J .. K .. L

我想是这样的(在两者之间挤压的一切A,并H进入A):

A .. H .. I .. J .. K .. L

有关如何压缩所有提交的答案,但我想保留一些最近的提交.我也不想压缩最近的提交.(特别是我需要保持前两个提交从顶部开始计数.)

当使用 合并分支时--squash，git 似乎不再能够确定分支是否已完全合并。如何使用现有的 git 命令快速检查这一点？

要重现，请创建一个新的 git 存储库：

$ mkdir tmp
$ cd tmp
$ git init
$ echo "bla" > ans
$ git add .
$ git commit -m "First commit"

创建new-branch带有提交的分支：

$ git checkout -b new-branch
$ echo "blabla" >> ans
$ echo "blupp" > zwa
$ git add .
$ git commit -m "Commit on new-branch"

创建another-branch带有提交的分支：

$ git checkout master
$ git checkout -b another-branch
$ echo "test" >> ans …

我有以下情况：我曾在一个功能分支（称为work1）上工作，我对该分支有出色的 PR。当我等待 PR 获得批准时，我想开始开发一个新的功能分支（称为work2）。问题是我公司的合并策略是压缩合并到 main 中，当我尝试合并work2到main.

这几乎就是我所拥有的：

1. 创建存储库和文件：

$ mkdir git_test && cd git_test && git init .
$ echo "test!" > test.txt && git add test.txt && git commit -m "added test"
[master (root-commit) 217c4bb] added test
 1 file changed, 1 insertion(+)
 create mode 100644 test.txt

2. 通过几次提交创建第一个功能分支：

$ git checkout -b work1
Switched to a new branch 'work1'
$ echo "1. Added this!" >> test.txt && git add test.txt && git …

我们可以使用rebase将多个提交压缩到同一个分支上的一个提交中吗？

举个例子,我创建了两个主题分支 - 来自master的issueA_1和issueA_2.我在两个分支中进行了几次提交,如图中所示(为了简洁,我在这里使用提交名称而不是提交哈希):

           -->  (issueA_1) - commitX1
          /
(master)--
          \
           -->  (issueA_2)
                   |
                commitY1
                   |
                commitY2

然后我做:

git checkout issueA_2
git rebase -i issueA_1

我将rebase文件更改为:

pick commitY1
fixup commitY2

在此rebase之后,提交历史记录如下所示:

           -->  (issueA_1) - commitX1
          /
(master)--
          \
           -->  (issueA_2)
                   |
                commitX1
                   |
                commitY1
                   |
                commitY2

我不再需要分支问题A_1,所以我这样做:

git branch -D issueA_1

issueA_2的提交历史还不足以合并到master中.我希望在合并到master之前将此分支的commitX1,commitY1和commitY2压缩为1个单一提交.这可能吗？

我收到了公关,并希望压缩提交,所以这很好.

我不确定我是否可以这样做或各自的作者必须这样做？当然,我希望保留作者的名字引用他们的壁球提交.

注意:这个问题不是关于我压缩自己的提交.

这是PR在Git中的样子:

或通过cli:

c:\Projects\Foo>git log --pretty=oneline
7fab9ae1031c13414909668f342582bdc8081f5a <Author - Red>
a02270b2014fd3995456773cd7badc7df0c72cf6 <Author - Blue>
6ae3d6c8b5a8b037c0e4dc88d24ec5598ff1933e <Author - Blue>
100f6513aacbe431b56f3082597749cddca284c8 <Author - Blue>
d263a5c8924053678f455b5ee8515bbb16aacf49 <Author - Blue>
c3cc5dbc13ac77e0a552a2d3132d255df3c7a6e4 <Author - Blue>
71f89b3f3dd583cd97d4a0806a973a4d1af64fe9 <Author - Red>
f14ef616a852f3a7311f4f7b9e05d460e0574422 <Author - Red>
015f30b3828828404b5549ee8a7df2aefdfa9424 <Author - Red>
9b22a4d2ded54cb754883d9d6418a39eb34df7cf <Author - Red>
33a10e9828d04cf82439a6c60b8cf4c0c2f122a3 <Author - Red>
4615c7747c4546809b29e063986c697c7c64cbc4 Added Specific naming rules, section.
b8ee154e38338022649caef40945c6f0297a59ce Added method parameters, section.
bc860c7609cc80caf41fc5944c1b39201019a80e Added Input and View Models, section.
ad6b3e4bee1cb9d8afcf9cd1fa8815769d80133b Fixed bad markdown formatting.
5929d5b38aad8bb7cc3da4976dd81883eab0f999 …

对不起,我是Git的新手,很难在Google上找到这些难以理解的问题(至少对我而言)的答案.

说我的名字是乔,我和我的同事鲍勃正在制作一个软件程序.

我们有上游Repo A,我们Repo A在本地机器上有克隆,我们在那里编码,提交和定期推送到同一个分支,比如master.我知道这在技术上并不是最好的方法,但是举个例子.

现在,如果我们都在处理一个文件会发生什么.他尚未推送的 Bob的本地文件包含内容

// awesome program
[some edits by Bob]

我尚未推送的本地文件包含内容

// awesome program
[some edits I made]

鲍勃推了推,一秒钟后我推了推.现在发生了什么？

远程文件是否正常

// awesome program
[some edits I made]

要么

// awesome program
[some edits Bob made]

或者,如果有办法,我希望它是

// awesome program
[some edits Bob made]
[some edits I made]

对不起的noobishness :(

我们可以压缩 中的最后 N 次提交Git。据我了解，我们可以使用git rebase -i HEAD~Nor压缩最后 N 次提交git reset --soft HEAD~N。

在这个问题的答案中（使用 Git 将我的最后 X 次提交压在一起）最受好评的答案建议是使用git reset --soft HEAD~N，但这不是被接受的建议。接受答案建议git rebase -i HEAD~N。因此我很困惑，更喜欢使用哪一个。

这些方法有何不同？推荐使用哪一种或安全使用哪一种？

当我压缩分支中的提交（使用 git rebase -i）时，我总是很恼火，因为压缩的提交与旧的提交而不是新的提交结合在一起。

我不明白为什么要这样设计。当我提交正在进行的工作 (WIP) 时，它表示未编译或未完成的代码。当我最终承诺“它终于起作用了！” 在合并之前进行提交和压缩，将这些 WIP 提交合并到“它终于可以工作了！”中更有意义。提交，而不是与之前的提交合并。压缩 WIP 本质上是用我知道无法编译的代码“破坏”了之前的提交。

为了解决这个问题，我的工作流程是压缩来自“它有效！”的提交。一直回到第一次 WIP 提交之前的状态。但这不是很愚蠢吗？其他人在做什么，这使得将 WIP 压缩到之前的提交有意义？

我不是最好的 Git 用户，每当我创建 PR 时都会遇到问题。基本上，当我做 PR 时，我会看到一个包含我之前所有提交的大列表，包括我刚刚提交的那个（我想合并到 Master 分支的那个）。我做的流程如下：

首先，我分叉了我们 Master 分支的副本，然后

git clone [local copy] 

然后我创建一个遥控器

git remote add upstream [main repo url]

然后每次我进行更改时，我都想添加到我的 PR 中：

git add [file1] [file2 ] ...ect

然后提交：

git commit -m 'blah blah blah'

最后推送到原点：

git push origin master

在此之后，我在 Github 上创建了一个 PR，它显示了所有以前的提交。有没有办法不列出所有这些而只显示我的最新提交？它显示已合并到上游 long back 并与其同步的提交。合并时不必选择特定的提交而只选择列出的提交会很好。

谢谢！

我正在尝试压缩我的提交并将我的分支合并为一个提交来掌握。这就是我正在尝试的。我切换到主分支，然后我就这样做了

git merge --squash <branch_name>

我得到

Automatic merge went well; stopped before committing as requested
Squash commit -- not updating HEAD

之后我承诺。但这就是我得到的

$ git commit -m "Resolved"
On branch master
nothing to commit, working tree clean

由于某种原因，更改没有得到反映，我收到消息没有要提交的信息。我已经浏览了堆栈上的许多帖子和问题，但到目前为止没有任何帮助。