Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitFlow considered harmful

endoflineblog.com

Post reply on HN
Print view View original

61–70 of 342 posts

Re: GitFlow considered harmful

#61

Post by plorkyeran »

solutionyogi wrote: post #50
sytse wrote: post #40

Earlier quoted context omitted.

My personal opinion is that it breaks history and CI tests for all the feature branches. But at GitLab we encountered customers that insisted on having a linear history after migrating from SVN. Therefore there is a function in the UI of GitLab EE to rebase a merge request when accepting the merge request. See http://doc.gitlab.com/ee/workflow/rebase_before_merge.html

Could you expand on what do you mean by rebase breaking CI tests? I don't see how that's possible.

The results from previous CI runs are no longer connected to the rebased commits, and most people don't have CI set up to retest each commit individually after a rebase.

I've never found this to be an actual problem in practice.

Re: GitFlow considered harmful

#62

Post by tehbeard »

solutionyogi wrote: post #50
sytse wrote: post #40

Earlier quoted context omitted.

My personal opinion is that it breaks history and CI tests for all the feature branches. But at GitLab we encountered customers that insisted on having a linear history after migrating from SVN. Therefore there is a function in the UI of GitLab EE to rebase a merge request when accepting the merge request. See http://doc.gitlab.com/ee/workflow/rebase_before_merge.html

Could you expand on what do you mean by rebase breaking CI tests? I don't see how that's possible.

Since a rebase changes the commit sha, I assume that's used as a reference for which version of the code the CI test was run against.

That said, shouldn't CI be triggered after the rebase anyway to confirm all still works?

Re: GitFlow considered harmful

#63

Post by ionforce »

Mithaldu wrote: post #2

I adore every person who advocates a mostly linear history and is able to elucidate that efficiently and elegantly. :D

Me too. I'm on team linear history and I still haven't gotten off my bum to make an article/presentation about it.

But I'm with you, brother!

Re: GitFlow considered harmful

#64

Post by radicalbyte »

I see GitFlow as a pragmatic workflow customized to cloud-based software. Master is auto-deployed, and Dev acts as insurance.

We're currently having lots of success with this:

* Always work in a feature branch. * Pull master + rebase feature branch when done. * Merge to master with --no-ff --edit and include a summary.

Rebasing feature branches keeps them readable and avoids continuous merges. Disable fast-forward keeps the log for /master abstracted to feature-level, but the details are available in the graph.

Major releases are branched, minors (bugfixes) are tagged. Bugfixes are made in master and cherry-picked into the release where possible.

Currently our CI build only works on /master, but in the coming month it'll build all feature branches which have been pushed to the main repository.

This is very similar to how Perforce streams work, but it's distributed. If you really hate distributed version control and love GUIs then I can recommend Perforce.

Re: GitFlow considered harmful

#65

Post by menssen »

I have come to actually like the two permanent branches approach. I know that for any repository that follows this model that:

* "master" is the current stable release

* "develop" is the current "mostly stable" development version

The first time you clone a repository this is an extremely helpful convention to quickly get your head around the state of things.

If you're doing it right (and don't use --no-ff, which I agree is unreasonable), I can't think of a scenario where this causes extra merge commits. Merges to master should always be fast forward merges.

Re: GitFlow considered harmful

#66

Post by solutionyogi »

tehbeard wrote: post #62
solutionyogi wrote: post #50

Earlier quoted context omitted.

Could you expand on what do you mean by rebase breaking CI tests? I don't see how that's possible.

Since a rebase changes the commit sha, I assume that's used as a reference for which version of the code the CI test was run against. That said, shouldn't CI be triggered after the rebase anyway to confirm all still works?

I see. But as you noted, one must do CI tests again after a rebase.

Re: GitFlow considered harmful

#67

Post by BillinghamJ »

jaimebuelta wrote: post #28

The approach discussed on the article seems to take into account only one possibility: you deploy master in prod, and it's always considered correct. That works for small projects, but in my experience, when you have a bunch of people (let's say 20) pushing code to a repo, you need several levels of "correctness" - branches: Work in progress. - develop: Code ready to share with others. It can break the build (merge c…

This can become very problematic.

For example:

Team is working on feature A and feature B. Each feature is developed on its own branch.

Feature A is ready for testing/integration, it is merged into develop.

Feature B is ready, it is merged into develop.

Now here is the problem:

Feature B is ready for release, but feature A is not. It is now not possible to merge develop into master without including both features.

The solution I use is to have master and branches. That's it. Master represents currently-running production code. Branches contain everything else.

This also happens to be how Github work. This article explains how it works with various levels of deployment before production - http://githubengineering.com/deploying-branches-to-github-co...

Re: GitFlow considered harmful

#68

Post by Mithaldu »

tokenizerrr wrote: post #60
Mithaldu wrote: post #58

Earlier quoted context omitted.

You introduce explicit revert commits?

Yes, this is a feature of git: https://git-scm.com/docs/git-revert I don't think rewriting the history of public branches is a good idea.

Please tell me what company you work at so i can avoid it. There's no other way to say it other than that your ideas horrify me.

Re: GitFlow considered harmful

#69

Post by radicalbyte »

sytse wrote: post #24

GitLab CEO here. I agree that GitFlow is needlessly complex and that there should be one main branch. The author advises to merge in feature branches by rebasing them on master. I think that it is harmful to rewrite history. You will lose cherry-picks, references in issues and testing results (CI) of those commits if you give them a new identifier. The power of git is the ability to work in parallel without getting i…

Sytse, do you mind if I ask a slightly OT question?

How does GitLab store the code-review data? Is it stored in the (or a) git repo? Is the feature compatible with rebasing feature branches before merge?

Also, pricing: I only just noticed that your pricing was per YEAR, not per MONTH. Most boostrap-pricing-page software is priced monthly and the user/year text is lowlighted. This has to be costing you sales.

Re: GitFlow considered harmful

#70

Post by Bahamut »

One thing that bothers me about GitFlow is that it mangles history with merges. Sometimes it becomes tricky to debug issues when history was created with GitFlow.

I would rather branch off of master, bring changes in via git am or rebasing when ready, then tag a release when it is ready to be released. If there is something wrong with master, the tagged releases serve as easy points to branch off of.

Post reply on HN