⭐️ Lean Branching - a git branching model to keep clean history

[DanPristupov]

We are thinking about adding to Fork a feature which would help teams to keep clean history.

As you know it's pretty difficult to have a clean history in git. I've got some ideas and tricks how that can be achieved. Briefly: create a separate branch for each feature, synchronize your changes with the main branch using rebase and merge back to main at the end. My point of view is similar to what Chris Manson suggests in his great article (https://simplabs.com/blog/2021/05/26/keeping-a-clean-git-history/, I really recommend to read it if you haven't yet).

Here's an example of a decent git history:

The commit history may look simple and clear, but making it so is surprisingly difficult and requires the use of some advanced (and dangerous) git features. In particular:

• rebase (to rebase on main)
• force push with lease (to update the remote tracking reference after the rebase)
• hard reset (if something went wrong and we want to start from scratch).

We are thinking about adding to Fork the ability to easily make those operations and perform dangerous things automatically (without hiding them, though!). Something like git-flow, but not so complicated and with a dedicated sync option. We called it "Lean branching" trying to reflect the approach but may be there could be a better name.

Goals:

• Be simple
• Keep history clean by default
• Do not introduce a naming convention. Fork can work with main, develop or master.
• Intuitive for advanced users
• Easy to explain to non-developers

The workflow is supposed to be like the following:

• Start a branch on main
• Commit changes. Sync with main as often as possible to minimize future conflicts
• When the work is done, finish the branch by merging it into main

So, there are just 3 actions:

1. Start new branch
Create and checkout new branch on main or origin/main (depends on which one is ahead)

2. Sync active branch

• rebase on the remote tracking branch (if needed)
• rebase on main (if needed)
• restore the remote tracking branch position on the new location using force push. So, if it was 2 commits behind the branch, it will remain 2 commits behind after the sync

If the active branch is main, sync will simply rebase it on origin/main

3. Finish active branch

• merge the current branch into main, but use fast-forward if the branch consists of a single commit.
  precondition: main must be in sync with origin/main

Simple example:

I've finished working on FW-433 and want to merge the changes into master:

Sync FW-433 with master first:

Finish FW-433:

Now I can test if everything works properly and then push master.

A few notes:

• Your changes will not be pushed or fetched automatically. You must do that yourself, same as you do now.
• All 3 actions are available in the Branch dropdown on the toolbar in Fork
• The underlying git commands can be seen in the activity manager if you click on the status control on the toolbar

Tanya and I have been using this feature 'as users' for some time and it works really well for us.

It would be great if you could try it and let us know what you think.

You can download the build here: https://cdn.fork.dev/prerelease/ForkWin-1.69.10.zip. Extract it somewhere and run fork.exe.

Use with caution, it's still in beta.

[Calneideck]

I'm running 1.69.10 but I can't see the new actions in the branch dropdown or anywhere else. Do I need to do something to activate them?

[DanPristupov]

@Calneideck
I just checked the source code. The items appear under the following conditions:

• there is local branch named main, develop or master
• the local main branch must have the remote tracking reference.

Is it possible that your local master doesn't have a tracking reference (upstream) to origin/master? You can change that in the context menu for local branch on the toolbar.

[Calneideck]

@DanPristupov Thanks, that was it! I had main that for some reason was not tracking origin/main.

[mloskot]

Is this the branching model that has just been released with the Fork 1.70.0?
Can be closed, I guess.

[DanPristupov]

@mloskot let's keep it open for now. We are still looking forward to hear feedback from people who tried it :)

I gave it a quick try. I really like this git methodology in general.
I usually interactive rebase, squashing as needed on the target branch.

I am used to working with branch protections, disabling any pushes to origin/main and enforcing FF-only merges in the git hosting service.
I think this will help folks who may not be keen to dive into advanced git usage.

I don't see myself using this in day-to-day operations but I can see it being helpful for others.

[lievendf]

I like it but I think it should be possible to do the actions while there are uncommitted changes as well, which is the case in most of my repos.
Having to manually stash these first, while the "manual" branch/commit/rebase/merge has the option to keep them there (stash and reapply automatically) feels like a step back...

[DanPristupov]

@LievenDeFoor this is a good point. I agree, Sync must also 'stash and reapply' when needed.

[lievendf]

* Do not introduce a naming convention. Fork can work with `main`, `develop` or `master`.

Could these names be made configurable?
We have long lived branches for released versions of our product that receive frequent updates.
Currently these can't use "Lean branching" as the names are "ProductName_MajorVersion" or similar...

[jnunnerley]

For 'force push with lease' to work correctly don't you need to disable automatic fetching ('Fetch remotes automatically' in General config) ?

[DanPristupov]

@jnunnerley may be I'm missing something, but I think automatic fetch is not related. --force-with-lease just checks that the remote branch on server is still on the commit as we expect it to be on. It's just a protection to avoid race conditions.

[jnunnerley]

@jnunnerley may be I'm missing something, but I think automatic fetch is not related. --force-with-lease just checks that the remote branch on server is still on the commit as we expect it to be on. It's just a protection to avoid race conditions.

The following details the issue

https://blog.developer.atlassian.com/force-with-lease/

Do you do the workaround?

[lievendf]

Another remark (sorry!):
We never use fast-foward merges and always create a separate commit when merging branches.
The "Finish branch" does not have this option and always does a fast-forward merge.
Can this be added as an option?

[Francoimora]

I was loving it until last update that made the sync operation mandatory. For non-dev users, rebase is harder to understand than merging (and it makes the history unclear for us). Could you let an option to let us merge without rebasing (like in the beta build) ?