This approach however could potentially collide with other tooling in the system. Some people end-up using system aliases for their git commands (e.g. In some cases it’s not as convenient having to type these commands, especially when there are no aliases for -autosquash or -fixup. Taking it a step further using Git Aliases This is very useful instead of doing a regular git rebase, as it makes it easier for our colleague to see how we applied the requested changes incrementally. Pay attention to how the -autosquash automatically sorted the fixup! commit under the commit it was fixing and also flagged as fixup, meaning that as soon as we save, the fixup commit will be squashed into its upper commit without changing its commit log message.Īs the PR review at this point is approved and the rebase is done, it’s now safe to git push -force and merge it. # f, fixup = like "squash", but discard this commit's log message # s, squash = use commit, but meld into previous commit # e, edit = use commit, but stop for amending # r, reword = use commit, but edit the commit message The way we would do it, is first making the changes, staging them and then executing the following command: Let’s say we want to fix the commit: * 744b43b - F1 where the variable that was requested to be renamed was first introduced. How? Incremental changes that can be automatically cleaned up prior to merging. If we git push -force after applying the many changes, it means our colleague will need to do another review iteration, increasing the chances of missing things or potential bugs that were introduced while rebasing.Īpproaching option solves options and. merge-commits solves this problem, however if this pattern continues, the git history will become too noisy and rather confusing.Īpproaching option sounds reasonable when working by oneself, but when working with colleagues, imagine there are multiple requests for changes within the same PR. Rebase the commit where this change was first introduced and git push -forceĪpproaching option will make our git history messy and hard to follow what this new feature branch is introducing.Create a new commit saying: “Rename variable per code review.”.There are different ways to approach this request: Our dear colleague then reviewed it and commented: “Can we please rename this variable to foo?”. We submit a PR (Pull Request) with the changes made in the my_new_feature branch. Git automatically prefixes them with fixup! and then with the same commit message it fixes. Making some of these commands available through Atlassian’s SourceTreeĪ git fixup commit is a special commit that fixes another commit up the tree.Scripts that I wrote which make it more convenient to use.The main focus of this blog post will talk about some use cases and practical examples of how we use it at work and why it makes the review process much more pleasant.Īdditionally, there are some other nice features that can be used in conjunction with git -fixup commits that I’ll briefly cover as well.Īs bonus, I’ll also provide some examples, such as: One very useful feature is git –fixup commits that have been there since forever, but not used by many as often as it should. Git has many different features that make it convenient to preserve clean version control history and collaborate with others without affecting productivity.
0 Comments
Leave a Reply. |