In this podcast, Krish discusses the importance of Git commits and their frequency within a team development environment. He introduces a scenario where multiple developers work on various features of different durations alongside bug fixes. Krish explains the traditional approach of working on a feature branch for a few days before creating a pull request, highlighting the potential challenges of merge conflicts. He proposes an alternative method of breaking down feature development into smaller tasks and reviewing commits more frequently, emphasizing the benefits of reducing merge conflicts and improving collaboration. Krish concludes by sharing insights into their team's implementation of this approach and hints at further discussions in future podcasts.
Summary
Discussion on Git Commits:
Introduction to the topic of Git and Git commits.
Acknowledgment of the broadness of the topic.
Focus on commits and their frequency, particularly in the context of team collaboration.
Scenario Illustration:
Illustration of a scenario with a team of developers working on various features.
Different durations for feature development mentioned (several days, a day, a few hours).
Mention of active bug fixing alongside feature development.
Git Workflow Options:
Description of one option: Working on a feature branch for a few days and then creating a pull request.
Discussion on potential merge conflicts due to isolated development.
Challenges posed by merge conflicts, especially in larger teams.
Alternative Approach:
Proposal for a different approach: Reviewing commits more frequently.
Explanation of breaking down feature development into smaller tasks.
Advantages of frequent reviews in reducing merge conflicts and improving collaboration.
Implementation and Process:
Description of how the proposed approach is implemented in their team.
Emphasis on frequent reviews and their integration with Slack.
Mention of the benefits beyond just reducing merge conflicts.
Podcast
Check out on Spotify.
Transcript
0:00
Hello. Hey everyone, this is Krish.Hope you're doing well and welcome to Snowpal podcast. Having said that, in today's podcast I want to talk a little bit about git and git commits in particular.
0:22
Again, this is a broad topic as well, just like just about just about everything else. So I want to focus on one aspect of it, which is commits and frequency of commits. Right. So let's take an example.Say you're working on a feature.
0:38
Let's assume for purposes of this monologue that we have a team of say, 4 to 5 developers with active feature development happening at all times during the course of any given day.Now let's say some of these features might take longer to complete.
0:59
Maybe they are several days long, while others could take a day or maybe less than a day.And maybe there are some enhancements that you're working on which might take just a few hours, right?That might just be a few hours worth of work. So let's say there are four or five developers, but there's a combination of different kinds of active development activity that's happening.
1:20
Plus, obviously you're probably doing some active bug fixing as well.Now let's take one of the items in this list, which is featured development, and let's say this is a feature that takes that.Say it might take the dev, the developer three days or so to complete.
1:38
Let's say it's over 2020, 2025 hours worth of work.Now there are multiple ways you could go about the git commit merge PR process.I'm just going to talk about again one little tiny aspect of it and then tell you what works or what has worked better for us than something else.
1:57
Now let's say there's one option which is to which is for the developer to create a feature branch and work actively on that branch for three days straight out, right?So they check out from develop, which is, let's assume has your latest and greatest changes.
2:14
You create a new feature branch off of develop and then you start working on your feature.Now you make a number of comments during the course of these three days to that particular branch. At the end of those three days, when you're done with that particular with that feature, you create a pull request and assign reviewers to that pull request.
2:35
Now who?Whoever ends up reviewing your changes, again that that could be depending on the process, you could have it many different ways in your team.But I'm just going to make it simple enough.Let's say there is one reviewer, they're going to review your changes, provide some feedback and then you go back and make changes and then they re review it and then finally they're going to merge it forward into mast, into develop.
3:00
Sorry, now that works.Except in the three days that you've been you've been working on.The other three, three or four developers have been working on implementing other features as well, or bug fixing.Now again, even if the code base is pretty big, you know it's it's likely unless you know you're a much larger team where you know you have clear separation of concerns and roles.
3:28
In a reasonably smaller shop, you're going to be touching a variety of different tiers of the code base. So even during the three day window, which again is just an example that I've taken here, a number of other changes could have happened and they might have been merged in the meantime to develop right?
3:47
Or you might have had some hot fixes that you fixed in production and merged it in the other direction to your active code base, dev code base, whatever be the case, Long story short, you you could run into a lot of merge conflicts, right?
4:04
Because you were in isolation for three days and that could be that could have been very well, five days or two weeks or whatever the length of time is.That doesn't matter. The longer it is just becomes more difficult. In our example it was 3 days, but still plenty of things transpired in the meantime. So you're going to run into a lot of merge conflicts.
4:22
Again, a good number of them should be automatically resolved.But you know, I'm talking about much conflicts that you have that that need manual intervention.And even in the scenario that needs manual intervention, it's possible that your reviewer does understand the changes well enough so they can resolve those conflicts.
4:40
But more often than not, or at least a smaller percentage of those conflicts, they may have to pull the the author of the code so they know what exactly happened and which direction the merge needs to go, Right?What?What do I need to pick?How do I resolve this merge conflict?
4:57
Now that can get pretty tricky and time consuming.Now, let's say for 24 hours worth of work, if you spend an hour doing or an hour and a half doing these code reviews and and merge conflicts, that's like 5% of the time, right?Which is a lot of time.And then it again, the numbers add up more, the bigger teams, more developers, more mergers, more commits.
5:18
You get into the situation where you're constantly resolving merge conflicts, which is not super worthwhile. So one, you know, we do get into those situations.But the other alternative, one of the other alternatives I should say, is try to do those mergers as, sorry, do those reviews as frequently as possible.
5:39
So hypothetically that the feature that took three days to complete, if you were to break it down and it's very likely that the developer had broken that down and let's say there were 10 checklist items or let's make it 9, just for ease of math and division here, let's say there were nine checklist items and let's presume three of them got done on each of those days just to keep all the math parts simple.
6:02
Now the first option, there were nine changes that made-up that feature and you reviewed all of them at the same time after the end of the third day.But if you were to have done it once a day, let's say you split, so you split it by three because it's three days worth of work.
6:19
You do a review at the end of each of those days, then obviously your likelihood that you're going to run into much conflicts is 1/3 and it's actually much lesser than that even though the math adds up to one third 33%.It actually in in reality and practice it could be more, but in reality I've seen that it's a whole lot lesser.
6:39
So what we now do, we obviously are are a smaller team, but we do a ton of work regardless if you're a smaller team.So we can make this happen easily.If you're a much larger team than large number of developers, then it's going to be a little more challenging, but but you have the benefit of more resources as well, right.
6:58
So maybe it all adds up in the end. So what we do is we review quite frequently.We actually do it even more frequently than once a day in this example. So in that case, if there are 10 checklist items, after every one or two items the developer pushes the request.
7:14
They may or may not necessarily create a formal pull request, but they merge and then we have it hooked to Slack so we know that the merge has happened even if they forget to tell you so.The reviewer can go pull the changes and we have a different process and I'll go into more further details and subsequent podcasts.
7:35
But it should suffice to know here that we go one checklist at a time or maybe two at a time or or some small number. So we reduce the number of conflicts. And it's not just conflicts because a bunch of other things got checked into develop in the meantime. It's also because the reviewer themselves is working on an active set of changes.
7:53
And the more frequently the two developers or three developers or the five developers, whatever the size of your team is, the the more frequently that they start pulling these changes, the less issues they're going to run into.I'm just here talking about a merge conflict, but there's plenty of other advantages that this process and approach brings to the table.
8:12
So hopefully some of that made sense to you.We'll more sorry.We'll talk more in the subsequent podcast. Thank you.
Top comments (0)