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

41–50 of 342 posts

Re: GitFlow considered harmful

#41

Post by chaitanya »

I have never understood why people hate merge commits so much. Their advantages are not insignificant: you know when a feature got merged in master, its much easier to revert a feature if you have a merge commit for it, much easier to generate a change log with merge commits, and you have none of the problems that pushing "cleaned up" histories will have: https://www.mail-archive.com/dri-devel@lists.sourceforge.net...

The main disadvantage, as the article rightly points out, is that it makes it much harder to read the history. But that's easily solved with a simple switch: --no-merges. It works with git-log, gitk, tig, and probably others too. Use --no-merges, and get a nice looking linear history without those pesky merge commits.

Re: GitFlow considered harmful

#42

Post by magicmu »

mmgutz wrote: post #32
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…

I don't agree with master being the production code. It's the default branch when you clone. I like to keep the production branch on a more explicit branch so my team knows they're dealing with release code.

I do something very similar; use master for dev builds that can be shared (since it's the default branch) and something like 'deploy' or 'deployprod' (which on second thought is a bit redundant) for release. Then, using a CI tool, you can have master go to a staging environment and deployprod go to production.

Re: GitFlow considered harmful

#43

Post by simias »

Touche wrote: post #35
mmgutz wrote: post #32

Earlier quoted context omitted.

I don't agree with master being the production code. It's the default branch when you clone. I like to keep the production branch on a more explicit branch so my team knows they're dealing with release code.

Why not just use tags?

You might want to cherry pick some commits from the dev branch into a stable branch from time to time (security fixes, things like that).

Re: GitFlow considered harmful

#44

Post by ryanbrunner »

Touche wrote: post #35
mmgutz wrote: post #32

Earlier quoted context omitted.

I don't agree with master being the production code. It's the default branch when you clone. I like to keep the production branch on a more explicit branch so my team knows they're dealing with release code.

Why not just use tags?

We use a master / development branch strategy. For us, the main problem with having one branch and tagging releases is that it's relatively common for work to continue on the development branch while the release branch is still being tested. For us, there's a 2 day period where we're testing out the upcoming release. Developers will be fixing bugs on this release branch, and also commiting new code for the subsequent release. If we had one branch with tags, developers would need to keep all their new code on feature branches until a release is completed, and the likelihood of accidentally releasing an untested feature gets a lot higher (one advantage of having two branches is that you can treat your production branch with a lot more care)

Re: GitFlow considered harmful

#45

Post by mpdehaan2 »

Posted a link to this prior blog of mine in article comments also - http://michaeldehaan.net/post/116465000577/understanding-whe... - but I'm a huge fan of rebase and topic branches.

One main branch is great, and also if working with a large number of contributors I really like a clean history, and makes things much easier to review.

It's kind of a shame something got branded with a slick name like "GitFlow", when "doing it the way you ought to be doing it" doesn't have a slick name :)

Re: GitFlow considered harmful

#46

Post by fragmede »

ryanthejuggler wrote: post #7

> ...the history of a project managed using GitFlow for some time invariably starts to resemble a giant ball of spaghetti. Try to find out how the project progressed from something like this... It's simple. Read backwards down the `develop` branch and read off the `feature/whatever` branches. Just because the graph isn't "pretty" doesn't mean it's useless. In general, I'm starting to dislike "XXX considered harmful"…

I'm not familiar with the gui git tools, preferring instead to work on the command line, but does whatever tool the author used to generate the graphs used on the web page support command line flags?

Specifically, git log --first-parent (--oneline --decorate) would look much better with the documented strategy. Instead of seeing all the commits in the branch, all that's shown is the merge commit. If you used the article's branch names, all you'd see is:

* Merge branch 'feature/SPA-138' into develop

* Merge branch 'feature/SPA-156' into develop

* Merge branch 'feature/SPA-136' into develop

If you actually used descriptive branch names, that would actually seem to be quite useful - see immediately see the features being added without seeing all the gritty details!

Re: GitFlow considered harmful

#47

Post by solutionyogi »

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…

It is better to have a messy but realistic history if you want to trace back what happend and who did and tested what at what time. I prefer my code to be clean and my history to be correct.

^^^ Couldn't agree more.

However, I don't know why people want to avoid rebasing feature branches. Rebasing feature branches means that you only have to resolve the conflict once and have a clean history for your release branch. Granted, it works well in my team where only a single developer owns a given feature branch.

Re: GitFlow considered harmful

#48

Post by Alexandervn »

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…

Yeah, we also use something like this for building a website/webapp (for a client) with 5-10 people.

- Feature branch: do whatever you want

- Develop: should be good enough for the client (product owner) to look at

- Release branch: should be good enough to be tested by the test/QA team

- Master: should be good enough for website visitors

Branches are meant to be shortlived and merged (and code reviewed) into develop as soon as possible. We use feature toggles to turn off functionalities that end up in develop but can not go to production.

Re: GitFlow considered harmful

#49

Post by realityking »

chaitanya wrote: post #41

I have never understood why people hate merge commits so much. Their advantages are not insignificant: you know when a feature got merged in master, its much easier to revert a feature if you have a merge commit for it, much easier to generate a change log with merge commits, and you have none of the problems that pushing "cleaned up" histories will have: https://www.mail-archive.com/dri-devel@lists.sourceforge.net..…

The problem, at least for me, is not the merge commit. They are indeed easily ignored. The problem is, that I don't want to see a dozen commits fixing typos or trivial bugs.

Re: GitFlow considered harmful

#50

Post by solutionyogi »

sytse wrote: post #40
brento wrote: post #31

Earlier quoted context omitted.

There is nothing wrong with rebasing a feature branch imho. Feature branches should be considered ephemeral. But it probably depends on your team and project size.

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.
Post reply on HN