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

Question

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?

Answer 1

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