英文:

Can git cherry picking last commit from throw-away branch damage the history in branch where data will be moved to?

问题

I've read about the unwanted side effects of cherry picking in regards to git history and ability to merge. However all examples I've come across assume that the branch, where a commit is cherry picked from, will continue to be actively developed-

In my case it is different. Since I am still learning about CICD (in particular in GitLab) I would often have the following approach:

1. Create a project skeleton in my master or develop branch depending on how the project is managed
2. Checkout a new branch for the CICD pipeline setup
3. Experiment in that new branch until the pipeline is fully functional
4. Merge back into the source branch (master or develop)
5. Delete the branch for the pipeline

The problem here is that my playground branch is filled with commits such as "Added log message to debug error XYZ" or "Trying to adjust XYZ". The number of such commits can be astonishingly high (I am working on a Django project currently where this branch accumulated over 200 commits until the pipeline was finally working!). In the grand scheme of things this will create clutter in the git history, which I would like to avoid (not to mention it shows my incompetence in setting up a CICD pipeline :D).

I was thinking of using git cherry picking to just select the last commit and move it to the source branch thus leaving no trail behind. It is important to note that, while working on my pipeline setup branch, the source branch is not changed at all.

Will this break something in the git history of the branch that will receive the new data?

英文:

I've read about the unwanted side effects of cherry picking in regards to git history and ability to merge. However all examples I've come across assume that the branch, where a commit is cherry picked from, will continue to be actively developed-

In my case it is different. Since I am still learning about CICD (in particular in GitLab) I would often have the following approach:

1. Create a project skeleton in my master or develop branch depending on how the project is managed
2. Checkout a new branch for the CICD pipeline setup
3. Experiment in that new branch until the pipeline is fully functional
4. Merge back into the source branch (master or develop)
5. Delete the branch for the pipeline

The problem here is that my playground branch is filled with commits such as "Added log message to debug error XYZ" or "Trying to adjust XYZ". The number of such commits can be astonishingly high (I am working on a Django project currently where this branch accumulated over 200 commits until the pipeline was finally working!). In the grand scheme of things this will create clutter in the git history, which I would like to avoid (not to mention it shows my incompetence in setting up a CICD pipeline :D).

I was thinking of using git cherry picking to just select the last commit and move it to the source branch thus leaving no trail behind. It is important to note that, while working on my pipeline setup branch, the source branch is not changed at all.

Will this break something in the git history of the branch that will receive the new data?

答案1

得分: 2

A cherry-pick is the wrong option here, not because of unwanted side effects, but because it's missing desired effects.

樱桃挑选不是正确的选项，不是因为不想要的副作用，而是因为它缺少了期望的效果。

A cherry-pick is roughly equivalent to making a patch of a particular change. It is useful, for instance, if you have a commit that fixes a typo in a file, on a branch that makes a whole bunch of other changes which are not ready yet. So you cherry-pick the typo fix into a new commit somewhere else.

樱桃挑选大致相当于创建一个特定更改的补丁。例如，如果您有一个修复文件中拼写错误的提交，而该分支正在进行许多其他尚未准备好的更改，那么您可以将这个拼写错误的修复挑选到其他地方的新提交中。

You want the opposite: you want to include all the changes on a branch, regardless of which order they were committed in; but you want to shorten the history as though they were all changed at once. You want to keep the final state, not the most recent change.

您想要的是相反的：您想要包括分支上的所有更改，无论它们是以哪个顺序提交的；但是您想要缩短历史记录，就好像它们都一次性更改了一样。您想保留最终的状态，而不是最近的更改。

This is referred to as squashing the commits, and can be achieved:

这被称为压缩提交，并可以通过以下方式实现：

• Using git merge --squash when you merge your branch to develop/master/wherever
• 当您将分支合并到develop/master/任何地方时，使用git merge --squash
• Using git rebase -i and setting all but the first commit to "squash" or "fixup" (the difference being whether you want git to combine all the commit messages)
• 使用git rebase -i，将除第一个提交之外的所有提交设置为“squash”或“fixup”（区别在于您是否希望git组合所有提交消息）
• Using git reset --soft to rewind history but keep the final state of the files, then committing them in a fresh commit
• 使用git reset --soft来倒退历史记录，但保留文件的最终状态，然后在一个新的提交中提交它们。

英文:

A cherry-pick is the wrong option here, not because of unwanted side effects, but because it's missing desired effects.

A cherry-pick is roughly equivalent to making a patch of a particular change. It is useful, for instance, if you have a commit that fixes a typo in a file, on a branch that makes a whole bunch of other changes which are not ready yet. So you cherry-pick the typo fix into a new commit somewhere else.

You want the opposite: you want to include all the changes on a branch, regardless of which order they were committed in; but you want to shorten the history as though they were all changed at once. You want to keep the final state, not the most recent change.

This is referred to as squashing the commits, and can be achieved:

• Using git merge --squash when you merge your branch to develop/master/wherever
• Using git rebase -i and setting all but the first commit to "squash" or "fixup" (the difference being whether you want git to combine all the commit messages)
• Using git reset --soft to rewind history but keep the final state of the files, then committing then in a fresh commit