Git Commits: An approach that works well for a startup

Let's talk about Git Commits and one aspect of it. So let's say you're working on a feature with 10 checklist items, right? Let's say you're working on a UI feature. There are...

We've gone through the requirements and the design, and we've identified that there are 10 development items that need to be completed for the feature to be considered done from a UI standpoint. These items are not equal in complexity or time consumption.

So one of those items could take a whole lot longer than the others, and so on. But regardless, when we go through the design, we identify as many items as we can. We certainly find others in the process of implementation, but let's say we've identified 10 of them, and we want to go about developing those items.

Here's how I would like to do it, but it's been a little difficult to implement that and follow through on that expectation, for understandable reasons, as you'll see. Ideally, I would like to take one item at a time and because we generally have them in a decent sequence, we implement the first one and then do a commit just for that one item, and then proceed to the next item in sequence, 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. I did speak about that in a different video. Then we would go through the review process.

If we don't like one item, we would like to be able to rollback that single commit, assuming that it doesn't shake the foundation of the ones above that. But the truth of the matter is the commits are not generally mutually exclusive, and we don't always get to work on them in the sequence that we had defined.

Long story short, the approach that I had suggested at the top of this video never seems to work for us. I don't know if it even works for anybody, or if anyone even intends for that approach to work. So what we do is we just take those 10 items, split them between team members, sometimes it's one person, sometimes more than one person working on it.

So those don't generally correspond to the actual checklist items. We create an intermediary branch, let's say we call it a feature merge branch, and then we do a squash merge into that branch. So that way, we don't have the history of all these 50 commits that I just mentioned.

So that's what we do. We create a merge into that particular branch, and then we deploy. And then after that, we just delete the branches as part of branch management and related activities.