Yay! You just finished upgrading this app! Man, that was huge, a lot of code to clean, a lot of outdated dependencies, a lot of shit to go through. Now let's spread the good news and tell the client what was done. The easiest way would be to go through a git log and maybe describe each commit a bit more, right?
Let's suppose you just don't like to commit often.
git log --since 2021/02/02
commit 2c15a50fab5db11b9f4dd98ab68aea3c81137680 (HEAD -> my-huge-upgrade-i-worked-on-for-2-weeks)
Author: Piotr Wilk <wilkuintheair@fake.com>
Date: Wed Apr 21 21:29:11 2021 +0200
upgrade rn
Ok, no worries, let's go through the changed files and we'll know. Let's just quickly see what's changed in these 87 files. Let's read each of these 87 files and for sure we'll come up with some solid, reliable summary.
This won't get any better, especially if you were working on it for 2 months in the evenings because it was your side hustle.
Now you see why it's better to commit often while upgrading?
Here's a better version of git log which can be more useful for this job.
git log --oneline --since 2021/02/02
837deb7e (HEAD -> rn-upgrade, origin/rn-upgrade) fix opening drawer menu
b495fdad fix back button on several screens
462cb878 fix propTypes warnings
60b9213e fix running the android app
61843322 migrate navigation's getParam to route.params?
17844756 update bugsnag
618a8f29 add missing bugsnag config
1835ca01 add missing android project include for codepush
bc7caa59 fix routes issues in the navigation
641d578b update bugsnag
04cdae03 update react navigation
c6ad1fe8 update i18next
d58d0c68 update react native billing
6c086db5 update codepush
b871cb46 fix NetInfo fetch
29c2f20d update lock files
50af2820 update more packages
9d5adfe1 update jetifier and lodash
1ec0b312 update fuse.js
f9e60fda change AsyncStorage imports
2dcf3f4c bring back App.js
3b05ac7e update react native community packages
78759ae9 remove TextInputMask from BlikPayment
0e254884 add flipper support
ed3f6529 bring back navigation
7e3dfa1a fix react import
364284dd bring back expo dependencies
d70a8818 fix building the app with unimodules
023033f5 add search paths
8148b765 ios recommended settings update
f4aeac54 update expo, add swift support
90171786 update ios to 11.0, update unimodules
031cc87c update AppCenter to v4.x, regenerate lock files
3aa3aec9 force using flipper v0.78.0 for iOS
93086945 fix react-native-text-input-mask issue when running pod install
d17612e3 yarn install
36d3a400 upgrade rn to 0.63.4 manually with upgrade helper
A bit better, right? It requires far less work in order to describe it to a client.
And if you don't like this amount of commits to be in your repo you can always squash it using git merge your-branch --squash or git rebase -i.
Also it's easier to track down potential issues using git bisect. What a great benefit!
What's your top benefit of commit often strategy?
Latest comments (3)
Good point - it helps with reporting and also with blogging later :)
I totally agree. I commit when I have the working piece of code, with meaningful commit message. That way it is SO much easier to find what you did in the past.
Yeah! But actually with this kind of work you often have not really working piece of code or even at the beginning not working at all. And still you should commit that IMO.
In the past I didn't do it, I committed only when it worked perfectly. And the result was 3, maybe 4 commits. Then few months later I was wondering "Damn, why this change is here?!"