kaleidoscope

There are scenarios when we want to apply the changes of an earlier commit in a repo, on top of the current repo tree of some branch in the same repo.  Or In some scenarios, we just want all the changes from an earlier commit of this repo into the current staging area and make some more changes before finally committing all the changes to the repo tree. For both scenarios, the git  cherry-pick  command   comes in handy. Git documentation  describes cherry-pick as git-cherry-pick — Apply the changes introduced by some existing commits. Given one or more existing commits, apply the change each one introduces, recording a new commit for each Let’s explain this with an example Step 1- Create a git repo mkdir git-example-cherry-pick && \ cd git-example-cherry-pick && \ git init Step 2- Add a few commits echo "First change" >> first.file && \ git add first.file && \ git commit -m "first commit" echo "Second change" ...

Expectation In an ideal world, One should be able to identify the product maturity model by merely looking at the commit logs for the  main/master  branch in the git. But it's possible only if, each commit represent a feature  Feature or  change  or  bugfix  or at least for an  incremental atomic change . Problem Having only meaningful commits directly contradicts what I call as “ no code left behind ” principle. Developers shouldn’t leave any code on their development machines. Instead, the code should be committed and pushed to the remote repo, every day before logging off. But sometimes one day is not enough to complete even  incremental atomic changes  suitable for a PR, let alone the code for the full feature. In those cases, this everyday push to the remote repo brings a lot of commits in the final Pull Request aka PR. In this post, I will show how can we combine all these commits before raising a PR, or as they call MR in GitLab. ...