![]() So, even though the commits m2 and f1 make the same changes, that is not clear from the diffs. In the diffs for a PR, GitHub actually shows you the accumulation of all the changes since the source branch diverged from the target. So, I was expecting the diffs in the PR to be just the differences introduced by the actual feature in commit f2. That would mean that the diffs would be the difference between the target branch of the PR, main, and the source branch, feature. My intuition was that the PR diffs would show me what changes will be introduced if I merge the PR. In that repository, m1 is an empty sfdx project m2 and f1 are additions to a class called MainClass, and f2 adds FeatureClass. To further illustrate this, I built the changes on GitHub here: And it’s the imperfections that teach us things. I would note that this is not an ideal situation, but we do not live in an ideal world. Now we want to merge the changes from the feature (commit: f2) back into the main using a Pull Request (PR). We have copied the changes from the main (commit: m2) into the feature by simply copying the code (commit: f1). Since the feature branch was created, the main and feature have both changed. The Main is our production code, the feature is where we are working on a new feature. ![]() Let’s say that we have two branches: main and feature. That journey updated my mental model for GitHub and I hope that it will also be a useful lesson for you when you are working with PRs on GitHub yourself. Reviewing a PR started me on a journey into “two-dot” and “three-dot” diffs in git. Recently, I was forced to realise that my model must be wrong. But what, precisely, do the diffs represent? I had a model for this in my head. You see a list of diffs from the files changed in the PR. Git never loses those commits and through commands like git log and git reflog they can be found and cherry picked back to life.You’re reviewing a Pull Request (PR) on GitHub. Sometimes a pull request might get closed without merging. Sometimes a feature branch may go stale and not get merged into main. Undoing changes and restoring lost commits This new patch commit can be cherry-picked directly to the main branch to fix the bug before it effects more users. The developer creates an explicit commit patching this bug. ![]() During that new feature development they identify a pre-existing bug. For an example scenario,say a developer has started work on a new feature. When a bug is discovered it is important to deliver a fix to end users as quickly as possible. This pick would enable the frontend developer to continue progress on their side of the project. The frontend developer could use git cherry-pick to pick the commit in which this hypothetical data structure was created. Maybe the backend developer creates a data structure that the frontend will also need to utilize. ![]() There may be some shared code between to two product sectors. Maybe a new product feature has a backend and frontend component. Often times a team will find individual members working in or around the same code. With that said git cherry-pick is a handy tool for a few scenarios. Cherry picking can cause duplicate commits and many scenarios where cherry picking would work, traditional merges are preferred instead. Git cherry-pick is a useful tool but not always a best practice. You can switch to the correct branch and cherry-pick the commit to where it should belong. For example, say a commit is accidently made to the wrong branch. git cherry-pick can be useful for undoing changes. Cherry picking is the act of picking a commit from a branch and applying it to another. Git cherry-pick is a powerful command that enables arbitrary Git commits to be picked by reference and appended to the current working HEAD.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |