Move to using a git flow

[Olical]

Right now everything is going into master (which I depend on with my work machine!) so stability is at risk. I propose moving to nvie's incredibly popular flow (which there's even tooling around).

So this repository should have a develop branch that is the very latest version. master is your latest stable version. When you want to add things you create feature/{FEATURE-NAME} and pull request it into develop. This is just touching on the subject though, I'd recommend reading that blog post I linked above.

Then we could implement semver so releases can be associated with a meaningful version. This allows users to stick at versions if they need to and only upgrade when desired. It should be more stable for day to day use and will allow you to write up release / upgrade notes when a new version is done.

[Olical]

Will integrate git-flow into core now that f seems fixed :D

I would like to see a develop branch in the core repository though. I can add some instructions on how to create a good PR (aim it at develop and document etc). Then we can start working off of develop as a bleeding edge that may break while releasing stable versions to master that "just work" for any other users.

[Olical]

Ah, f still doesn't seem to work in the magit / magit-gitflow buffer. Still tries to find a character. Odd.

[syl20bnr]

@Wolfy87 I did nothing for magit-gitflow for now ;-)

I was planning to add magit-gitflow this evening so your PR is welcome.
I'll continue the f quest then and finish a first iteration of the contribution guideline with git-flow instruction.

[syl20bnr]

@Wolfy87 Added magit-gitflow with b36b43a. See the commit message for an explanation of the fix for the f binding.

[Olical]

It works perfectly! 👍

[Olical]

This is done now really, we have magit and a develop branch. All there is to do now is use gitflow for creating and merging your feature branches.

Re: Your question about updating branches from their parent. The idea is to use git merge --no-ff for everything which preserves all of the commits but also creates a merge commit on the end. So you have granular commit history but also one big unified diff that you can use git revert on to revert the merge while maintaining history.

When you look through the logs then you'd see commits going into the branch, then one revert commit which undoes the changes. Best of both worlds. If you learn how to use magit gitflow it will basically do all of it for you :)

[Olical]

Just a note on rebasing: It completely rewrites history, so you have to force push those commits back over the old versions from the alternate time line. Yes this works, but it causes a lot of headaches down the line, all in the name of a "clean" log. We used to rebase at work and I helped move everything to merging, we're far better off now in my opinion.

I can turn on git annotations and see who changed each line and why, the entire code base is commented because of this. Before we moved to gitflow everyone squashed and rebased, so entire files were owned by one person and commit so I had no idea why things changed or who actually changed them.

[syl20bnr]

Thank you for the explanation, I know understand it better. For the case of feature branch is a rebasing a good practice ? I don't want to keep alive hundreds of feature branchs.

I wonder why Github is a mix of this, commit are replayed on top of the destination branch and a merge commit is created. Is that only to be able to know who merged the commits ?

[Olical]

Feature branches should not live very long, so you shouldn't need to. If you are the only one working on the branch you can rebase and force push if you want, but if anyone else had your branch cloned it would invalidate their copy. One of the main reason I'm generally against rebasing.

I, personally, prefer git merge --no-ff develop to update my branch to develop. This leaves a paper trail of which merges have happened and makes the graph completely traceable. It may not look as clean, but it's far more functional.

So rebase if you ever need it (which you shouldn't very often!) but I prefer merging because it doesn't rewrite history.

It's not just GitHub that does the mix, it's git. The merge is the process of taking the missing commits from one branch and copying them into another. The merge commit on the end may contain conflict resolution but also contains information about who performed the merge, when it happened and with which branches. The merge commit is what you would use git revert ... on.

If you rebase / squash, you have no history of the merges or the separate commits. You lose so much information for the sake of a pretty git log. You can use things like git log --merges if you want to see all of the features that have gone into develop.

Shall we close this now? :)

[syl20bnr]

Thank you for the great explanation, I think we are ready to go with git-flow and close this issue. I will make mistakes while getting used to it, open an issue as soon as you detect something wrong ;-)

Thank you !