The superpower to perform version control on reality. (Git)

Imagine this universe (the current branch), which is made up of a series of events (commits).

Having this ability to allows us to:

- undo events (git reset/git revert)
- reorder events (git rebase)
- transfer to another universe (git checkout)
- derive a new universe from current universe (git checkout -b)
- delete a universe (git branch -D)
- apply an event from another universe (git cherry-pick)

and my favorite:
- merge universes and their events (git merge)

we have to resolve conflicting events, of course.

What else? ;)

Senior Dev at work told me to cherry pick commits from another branch....later found out that it is an actual git command ! 😅

git cherry-pick <commmit>

My dad said I can't be a farmer.
The I did this:
`git cherry-pick b6b27bccc3c6abbf2551a8c4a3e59dd36fc1af18`

We'll he was right coz this is the closest I'm gonna get.
Oh!, wait; I can have a server farm.

!rant.
Here's some useful git tricks. Use with care and remember to be careful to only rewrite history when noones looking.

- git rebase: powerful history rewriting. Combine commits, delete commits, reorder commits, etc.

- git reflog: unfuck yourself. Move back to where you were even if where you were was destroyed by rebasing or deleting. Git never deletes commits that you've seen within at least the last 50 HEAD changes, and not at all until a GC happens, so you can save yourself quite often.

- git cherry-pick: steal a commit into another branch. Useful for pulling things out of larger changesets.

- git worktree: checkout a different branch into a different folder using the same git repository.

- git fetch: get latest commits and origin HEADs without impacting local braches.

- git push --force-with-lease: force push without overwriting other's changes

The more i use git.. more the fun it is.. Just found out the usage of rebase and cherry-pick.. I have read about the implications of these commands in a shared repo.. But it is fun to use it in a solo repo..

When I asked to Experienced Senior about cherry pick command in git.

I got 30 Minutes big lecture about Parent-Child Node.

But Cherry Pick, He did not pick for explain. 😡

When you git cherry-pick for the first time, screw up, rebase-drop, repeat, screw up again, and end up just pasting the correct versions of the files and commiting on top of the branch.

Dirty, but it works.

let me preface with the fact that I'm now known at my new job for being the resident cli hipster. I can't lay any claims to knowing if it's "better" but I like it, I don't care if you do or don't, it just works for me and my flow

so at my job, we generally squash all our commits into one commit and delete the source branch upon merging; i accidentally committed all my work to an old, already merged branch, so my boss tells me it would be more of a PITA with the weird references we would encounter by merging the branch again, rather than just cherry pick the commits into a new branch, which i'm like "eh, fine.".

HIM: "You want to share your screen so we can resolve this?"
ME: "k"
HIM: "Oh, you won't be able to do this in a terminal, you are going to have to load up a GUI of some sort"
ME: "lawlz, no you don't"
HIM: "i highly doubt you will be able to accomplish that, but if you wanna make an ass of yourself, i'll humor you"
ME: "yeah, watch this"

> git log > log.txt
> git checkout <new branch>
> git cherry-pick <copy-paste-full-commit-hash-here>
> git push

ME: "done"
HIM: "what? there's no way you did it that easily, where are all your other commits???"
ME: "i usually try to amend my commits since we squash them anyhow. it really helps in situations like this"
HIM: "well, you go girl"

roll that up in your fancy degree and smoke it, why don't ya?

Git Cherry-Pick is the discovery of the century 😳

Sitting in a bar with a senior colleague (Me - Student part timer, Him - 15+ Years of experience).
We started talking about our projects and he mentioned that after this, he'd get to spend his evening fixing a git merge, which went wrong because one of his teammates used cherry pick and thus messed up the history a bit (oversimplified).
So he tells me he'd be spending hours to get an overview of his colleagues codes (multiple devs and only team leader knows who does what exactly).
So I suggested he revert these cherry picked commits and so could maybe solve the problem in less time.
He thought about it... Told me HE didn't think of that and thanked me for my help.

Long story short: Today was a good day :3

is it necessary to have cherry picking a part of git branching/release process?

we have 3 branches : develop, release and master.

currently every dev works on feature as follows : they make a branch out of develop, write code, raise pr against develop, get it reviewed and merge back to develop. later the release feature list is generated, and we cherry pick all the release related commits to release branch, and make a prod build out of release branch. finally, the code is moved to master and rags are generated accordingly.

so the major issue with this process is feature blocking. as of now, i have identified 4 scenarios where a feature should not be released :

1. parallel team blocker : say i created a feature x for android that is supposed to go in release 1.2.1 . i got it merged to develop and it will be cherry picked to release on relase day. but on release day it is observed that feature x was not completed by the ios dev and therefore we cannot ship it for android alone.

2. backend blocker : same as above scenario, but instead of ios, this time its the backend which hasn't beem created for the feature x

3. qa blocker : when we create a feature and merge it to develop, we keep on giving builds from develop branch adter every few days. however it could be possible that qa are not able to test it all and on release day, will declare thaf these features cannot be tested and should not be moved to release

4. pm blocker: basically a pm will add all the tickets for sprint in the jira board. but which tickets should be released are decided at the very late days of sprint. so a lot of tasks get merged to develop which are not supposed to go.

so there's the problem. cherry picking is being a major part of release process and i am not liking it. we do squash and merges, so cherry picking is relatively easy, but it still feels a lot riskier.

for 1 and 2 , we sometimes do mute releases : put code in release but comment out all the activation code blocks . but if something is not qa tested or rejected by pm, we can't do a mute release.

what do you folks suggest?

Git cherry-pick 35 commits, another dev commit to the wrong branch, and these commits will be released first

(!rant || git)

Non-techy friend (n): you know what cherry pick is?
Me: cherries?
N: you dont know that?
Me: well, i love cherries...
N: i am disappointed of you.
Me: what the f...ing hell is that?
N: you know the git thingy you are always doing...
Me: i have never heard of that...
N: well use it every time before and after you commit.
Me : (not believing, but kinda believing) ok.
A few days later...
Me: nnooooooooooooo.!
Messed up 3 hrs of work

-------------------
What really is cherry pick guys?

You should produce
shirts that are boldly written ”Git Cherry-Pick Saves!”.
It has redeem me from messed up conflicts. conflited files = 89.
How the fuck am I going to review 89 files, when deadline is just two days from now.

git cherry-pick -n <commit>

The "-n" is alias for "--no-commit" and it applies the content of the target commit into your working directory without making any commit. Usefull if you want to cherry-pick many commits, tweak them and make a new one or simply want to grab some functionality into your index.

What's yours well-appreciated but not-that-well-known git functionality?

I have a git feature branch with my commits but also have merged the changes from the main branch to resolve merge conflicts before PR.

But now need to create a special release with just my changes.

So I think have to cherry pick all my commits on my branch some the last Release. How can I do that?

Develop (others) + Feature => Develop

Want to create new branch

Last Release + Feature (but only my commits since last Release)