Another GIT framework workflow

Disclaimer: This post is mostly random thoughts. You may like some ideas and pick'em in your own GIT workflow, after all, every team is different.

Here is another post on my list of regrets. I have to say when I first write about them, they don't seem in my mind too bad as they eventually become after I learn more about the subject. However, I will say at this time, I've worked with a pattern like this for a while now.

I've to say it looks much like GIT flow, but it has some differences. It's more to complement than an alternative. This has worked for me in small teams, and mid-size teams (up to 7 people working in the same repo at the same time)

TL; DR: New Branch, Commit, Pull Master, Rebase, Repeat.

New Branch

Create a new branch. In your work, you may have only master or master for stable code and develop for unstable code, or maybe you work with a different set of branches. I don't know. Nobody has to tell you how many branches you should have.

But, you should create one branch for each feature/bugfix/refactor you want to do. This ensures you can update your code in the most straightforward way with the branch you are supposed to sync with.

This new branch, you can call it whatever you want. You should be consistent in your team about the branch and commit naming, but that's outside this guide. As I say, each project is different, and the could follow different patterns for this.

Commit

Commit all your changes to your new branch. Again, up to you about how granular your commits should be. You can allow amend in your team and have just one big commit or commit each change individually, or a mix of both, really up to you.

What matters at this point is for you to have all your changes in your branch. By now, your branch may be outdated, so you have to update it with the latest from your sync branch.

Pull Master

Well, you don't have to pull your master. This is your sync branch. The one from where your feature branch started and will be merged to. It's likely for this to be newer than the one you have.

So, checkout to your sync branch, and pull the changes. Now you have your sync branch up to date. But, your feature branch is outdated. You would need to fix that before you make a pull request.

Rebase

Check out your feature branch and rebase against your sync branch. I really prefer to rebase over merge, because you have more control. Each of your commits will be applied over each of your sync branches, and if you have any conflicts it probably will be less, than having a merge. Also, I found rebase to be easier to resonate with.

Repeat

Do your PR. Check your comments. Fix them. Commit. Pull Master. Rebase.

But you won't be able to push this time. Unless you do a push --force. And this is a scary thing, and maybe most people won't agree with this point but do it. Do a push force. Most of the time you will be working in a branch alone (again, this is from my experience in small to mid-sized teams). If you are working with a teammate in the same branch, they could do a rebase against the remote feature branch from their local feature branch.

Merge your code to your sync branch.

Repeat all over again for another feature.

That's all folks!

I hope you find this helpful. I'll be looking forward to reading your opinions about this. Again, this is some pattern (?) that I've been using by years now. Every team has their own structure about the branches and rules about the commit naming, but this pattern repeats itself. Maybe you have encountered a pattern like this as well.