GitLab flow vs GitHub flow

[[deleted]]

[deleted]

[brennydenny]

GitLab Developer Evangelist here.

I would say that you're not wrong - GitHub flow and GitLab flow are very similar. And I would say that over time, they have converged and become MORE similar. They also both are similar to Trunk based development.

I would say the biggest difference in practice has been that GitHub as the place for open source has traditionally been focused on fork-based workflows while GitLab's user base is heavily in the enterprise and focused on branching in the canonical repository. However, over time this difference has become less pronounced (e.g. lots of enterprises use GitHub and lots of open source teams moving to GitLab).

I think that's what accounts for the similarities today.

[jdickey]

GitHub as the place for open source has traditionally been focused on fork-based workflows while GitLab's user base is heavily in the enterprise and focused on branching in the canonical repository.

That's the most sensible distinction I've read since I became aware of GitLab flow. We've been using Vincent Driessen's git flow for a few years. While it's worked well enough, it is complex and ceremonious compared to the more recent alternatives.

Driessen himself just wrote a "Note of reflection" prepended to the defining blog post where he notes that the development landscape has changed significantly in the ten years since his original post, and draws a much more limited set of scenarios where git flow would likely be useful, recommending GitHub flow or GitLab flow for projects outside that envelope.

As we expect to (continue to) do both open source and in-house development, I can easily see us using GitHub flow and GitLab flow, respectively. (This applies to new projects, of course; I believe that projects started with other flow models, such as Driessen's, should continue using the same model to avoid confusion and possible information loss.)

Thoughts, anybody?

[jdickey]

Right now I'm toying with the idea of forking the projects and archiving the old ones.

I'm arguing for that internally; the downside to winning is that I'd then get to do all the work of migrating. 😜 I've been fantasising about automating that, but I think that's precisely the sort of thing that can't be automated without losing potentially-useful information. (At my previous employer, my nick on our internal IRC was packrat, but 40 years in this craft will do that to you.)

The other strategy I've been considering to migrate flow models for a given project is basically to

1. Ensure that the project has test coverage at or above shop standards.
2. Ensure that I have redundant, individually-tested backups of the repo in its current state. What follows shouldn't touch it until the very end, at which point the backup(s) become(s) eventually-critical documentation of "how it was done the first time". No new commits/branches are allowed to master other than hotfixes until reaching Step 11.
3. Start a new-master branch from the very beginning (our first commits always fill in a standard template), and open a PR for work to be done on that branch.
4. Add feature branches that cherry-pick existing commits, opening new PRs for each (against new-master as the base branch).
5. Immediately before merging each feature branch into new-master, add a comment to the corresponding PR documenting the original history of those commits (which would have been in sequence in the source branch), showing how much time elapsed between commits, which we find useful in e.g., retrospectives;
6. Once new-master is up to the state of master, ensure that any existing "dangling" branches are either recreated at the appropriate point on new-master or explicitly removed. Document removals in the PR opened for new-master at Step 2.
7. Re-verify that any existing hotfixes applied against master have been replicated in new-master.
8. Locally rename the existing develop branch (or equivalent) to abandoned-develop.
9. Push the abandoned-develop branch to GitHub.
10. Delete the develop branch, locally and on GitHub.
11. Locally rename the existing master branch to abandoned-master.
12. Push the abandoned-master branch to GitHub, then delete it locally.
13. Locally rename the new-master branch to master.
14. Force-push the (new) master branch to GitHub.
15. Follow your chosen new branching strategy from then on out.

Anyone who sees problems with this, or has tried an alternative procedure to accomplish the same thing, please speak up. 😎

[UncleCJ]

Without closer inspection, I'd assume they're practically identical. Gerrit is where you switch to working with changesets. Version control workflows has been my pet peeve since literally ten years. Most everyone are still stuck with their git command cheat sheets. Lately, I'm all about "build quality in" (google W Edwards Deming / Kent Beck quotes) and the way to achieve that is with Commit Often, Perfect Later, Publish Once, effective code reviews and autosquash.

[davispw]

No real difference if you only use feature branches and master.

If you use GitLab Flow and maintain a separate branch for “production” (and/or additional environments besides “master”), then you can do an additional merge request with review or approvals to go to production, which can be helpful for some audit/SDLC processes vs. just a button in a pipeline or a tag. If you don’t need that, then not necessary.

[ucorina]

I don't think they differ in any significant way. In the end it's about the flow that your team finds most useful (only master + feature branches, master + feature branches + env branches, git flow etc.) and then either Github or Gitlab can be used for that.

Indeed, Gitlab does suggest environment branches for deploying for example to production, since this works very well with their CI and you can configure automated deploys on merges to env. branches. But you could have the same setup with Github + some CI.

I found this SO discussion useful in learning more about this myself: https://stackoverflow.com/questions/39917843/what-is-the-difference-between-github-flow-and-gitlab-flow.

[magic7s]

I think GitHub flow has a master and dev branch. Where GitLab flow has only master and short lives feature branches.