In Part 1 of this article (link to part 1 here), I talked about organizing the code itself: architecture, Clean Code, and SOLID. But well-written code isn't enough if the team around it doesn't have a clear process for versioning, documentation, and workflow. That's what I want to talk about now.
I Had Been Doing It for a While — I Just Didn't Know the Name
I remember a coworker asking me to "create a feature branch off of develop." I did it almost without thinking, since it was exactly what I'd already been doing for years. But that's when it hit me: "wait... does this have a name?"
That's how I found out that "automatic" workflow I'd been using — stable main branch, feature branches, isolated hotfixes — already had a formal name: Git Flow.
And that wasn't the only time. Earlier in my career, it was common to follow instructions ("do it this way," "follow this pattern") without understanding why, or even knowing there was theory behind it. Practice arrives before the name, and only later — out of curiosity, or in a conversation with another dev — do you discover the formal label for what you were already doing. It's not a lack of competence, it's just the natural order of day-to-day learning.
