Git Commits: An approach that works well for a startup
Git Commits: An approach that works well for a startup
Snowpal Podcast: Much like Git Workflows, the process to manage your git commits also has a bearing on your team's productivity.
In this video, Krish discusses the challenge of managing Git Commits when working on features with multiple checklist items. He explains the ideal scenario of committing each checklist item separately for a clean commit history but acknowledges the practical difficulties due to interdependencies and non-linear work sequences. Instead, the team opts to divide checklist items among members and collectively push changes to the feature branch. Before merging into the develop branch, an intermediary branch is created to squash merge commits, balancing between a detailed commit history and a cleaner one. Despite limitations, this approach has proven effective for the team. Krish concludes by sharing their deployment process and hopes that the explanation benefits viewers seeking insights into git workflow management.
Summary
Krish introduces the topic of git comments and focuses on one aspect related to working on features with multiple checklist items.
He mentions identifying 10 development items required for a feature to be considered complete from a UI standpoint, noting that these items vary in complexity.
Ideally, Krish suggests committing each checklist item separately to maintain a clean commit history and facilitate easy rollback if needed.
However, he acknowledges the difficulty in implementing this approach due to the interrelated nature of checklist items and the non-linear sequence of work.
Krish explains that the team typically divides the checklist items among team members and pushes changes to the feature branch collectively.
Before merging into the develop branch, an intermediary branch is created to squash merge commits, ensuring a cleaner commit history.
He discusses the trade-offs between maintaining a detailed commit history with multiple commits versus having a cleaner history with squashed commits.
Despite the limitations, Krish states that the process has been effective for the team so far.
The final steps involve deploying the changes, followed by branch management activities such as deleting feature merge branches.
Krish concludes by expressing hope that the explanation of their process will be helpful to viewers.
Podcast
Transcript
0:05
Hey everyone, hope you're doing well.This is Krish.In this video I want to talk about git comments and one aspect of it.So let's say you're working on a feature when it has like 10 checklist items, right?So you have to do.Let's say you're working on a UI feature.
0:22
We've gone through the requirements and the design and we've identified that there are 10 development items that need to be complete for the feature to be called done from AUI standpoint.And these items, they're not equal, meaning that they're not equally complex or time consuming.
0:41
So they one of those items could take a whole lot longer than the other and so on and so forth.But regardless, when we go through the design, we identify those items that are as many as we can.We certainly do find others in the process of implementation, but let's say we've identified 10 of them and we want to go about doing the development of those items.
1:01
Here's how I would like to do it but you know it's it's been little difficult to to implement that to follow through on that expectation and for understandable reasons as you'll see if you have 10 items, ideally I would like to take one item at a time and because we have them generally in a decent sequence a decent quote UN quote decent sequence.
1:24
So we implement the first one and I want to be able to do a commit just for that one item and then do a second commit for the second item and and then all the way through to the 10th item.So in that ideal hypothetical scenario, there would be 10 commits that would make up that feature branch and then a pull request is created to be merged forward to develop interim.
1:44
And I did speak about that in a different video.And then we can we would go through the review process And if we did not like one of those changes, assuming you know, because when you have 10 items, even though they all collectively contribute to a feature, you could reasonably assume that they are mutually exclusive of each other to whatever extent, just take that as a grain of salt.
2:06
So what I'm trying to say is if we don't like one item, we would like to be able to pull back roll back that single commit assuming that it doesn't shake the foundation of the ones above that.Here's how I would like to do it but you know it's it's been a little difficult to to implement that to follow through on that expectation and for understandable reasons as you'll see if you have 10 items.
2:29
Ideally I would like to take one item at a time and because we have them generally in in a decent sequence, a decent quote UN quote decent sequence.So we implement the first one and I want to be able to do a commit just for that one item and then do a second commit for the second item and and then all the way through to the 10th item.
2:48
So in that ideal hypothetical scenario there would be 10 commits that would make up that feature branch and then a pull request is created to be merged forward to develop interim.And I did speak about that in a different video.And then we can, we would go through the review process.
3:04
And if you did not like one of those changes, assuming you know, because when you have 10 items, even though they all collectively contribute to a feature, you could reasonably assume that they're mutually exclusive of each other to whatever extent, Just take that as a grain of salt.
3:21
So what I'm trying to say is we don't like one item.We would like to be able to pull back, roll back that single commit, assuming that it doesn't shake the foundation of the ones above that.But the truth of the matter is the comments are not generally mutually exclusive the the checklist items and we don't always get to work on them in the sequence that we had defined either.
3:43
Because you know, sometimes you work on item number one and you you realize items five and six are kind of related.So it's easier to knock them out at that point of time so you start working on them.So now this commit would actually end up having three items, and other ones might have two.And sometimes you you you end the day without completing an item because you just didn't get the chance to complete it on that particular day.
4:06
So you still want to push your changes for fear of losing it or for many other reasons, right?Even if you don't push, you're still going to do the commit, so it's local to your system.So Long story short, the the approach that I had suggested at the top of this video never seem to work for us.
4:24
I don't know if it even works for anybody, right?Or if anyone even intends, intends for that approach to for that approach to work.So what we do is we just take those 10 items, split it between the team members, sometimes it's one person, sometimes more than one person working on it.And once we are done with all of them, we push that the feature branch.
4:43
And then before we merge to develop interim, we also do one other thing.I did not mention that in the other video, just not make it even more complex than it may have already gotten.But because of the fact that there could be 10 checklist items and 50 comments, because we want to commit something at the end of the day we we made some incorrect comments, we are fixing them and committing it back.
5:03
So those don't generally correspond to the actual checklist items.So we create an intermediary branch, we call it, let's say we call it some feature merge branch and then we do a squash merge into that branch essentially.So that way we don't have the history of all these the 50 comments that we that I just mentioned.
5:24
And then we have a clean commit.So the only unfortunate thing is when you have like 10 checklist items, we have a choice, it's choosing between the devil and the deep sea.Either we have like 50 comments not all of them makes sense, so it becomes too polluted or we have we do the squash merge and there is a single commit and sometimes it's more than one because after we squash merge we we might make other changes as part of the code review process.
5:47
But but ignoring that for a second it could possibly be just a single commit.So now we we have no way to track the changes to those 10 individual checklist items.So that's the downside.But but it's it's worked all right so far.
6:03
So that's what we do.We create merger into that particular branch and then we deploy and then after that we just delete the branches as part of you know branch management and related activities, we delete these the feature merge branches.
6:21
So anyways that's that's the process we follow.Hopefully that helps some of you. Thank you.
Snowpal Products
Backends as Services on AWS Marketplace
Mobile Apps on App Store and Play Store
Education Platform for Learners and Course Creators