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

91–100 of 342 posts

Re: GitFlow considered harmful

#91

Post by Mithaldu »

sytse wrote: post #88
Mithaldu wrote: post #51

Earlier quoted context omitted.

Looking at the recent history i can see how you'd come to like it. You seem to mostly be doing merges or documentation changes, which probably means you don't have to do a lot of history spelunking to fix bugs caused months ago. Are you sure your developers feel the same as you do? Are you sure they're willing to be open enough to you about their misgivings?

I think the majority of people on our team don't like rebasing because it makes spelunking harder in some cases. But there are certainly people that preferred having some commits rebased so it was easier to revert them (reverting a merge is possible but harder). Although I'm not an active developer myself I think my dislike of rebasing everything is shared.

> I think the majority of people on our team don't like rebasing because it makes spelunking harder in some cases.

Would you elaborate on that please? I don't know what your situation is like that would cause rebasing to make spelunking harder.

> reverting a merge is possible but harder

Funny, someone else further down claimed reverting merges is easier. :)

Re: GitFlow considered harmful

#92

Post by pc86 »

maratd wrote: post #85
BillinghamJ wrote: post #67

Earlier quoted context omitted.

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. Th…

I'm a bit confused, why are you merging things into develop if they're not ready? If Feature B isn't ready, it should stay in its own branch until it is. Develop is for code that the developers say is ready. You might have bugs, poor merge resolution, etc, but any fixes made should be quick and should pave the path toward code that can be merged into master. If the problems are major, revert develop. Master, on the o…

In the above example, say Feature A gets the go-ahead from the business user/product owner/whatever, and Feature B doesn't. From the dev standpoint both are complete but there may be some business reason to hold up Feature B. The owner(s) of Feature A are likely not going to understand why anything to do with Feature B has to hold up their release.

Re: GitFlow considered harmful

#93

Post by jrochkind1 »

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..…

> its much easier to revert a feature if you have a merge commit for it

I like this theory, and generally like merge commits because of it -- but in practice, I've found it still _really really hard_ to revert a feature even if I have a merge commit. Simply reverting the SHA of the merge commit does not, I think, do it, git complains/warns about that. I have to admit I still havent' figured out how to do it reliably even with a merge commit!

Re: GitFlow considered harmful

#94

Post by Mithaldu »

sytse wrote: post #83
solutionyogi wrote: post #66

Earlier quoted context omitted.

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

Indeed you need to do them again. But you also have to rerun them after a merge anyway. The problem is that you can no longer see which commits that you merged where green before the merge. For example is very useful if the merge itself breaks the tests (uncommon but it can happen).

Edit: There's a well-written solution for that here: https://news.ycombinator.com/item?id=9745367

Re: GitFlow considered harmful

#95

Post by sytse »

radicalbyte wrote: post #69
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.

You're very welcome.

When you accept a merge request the title, description and a link to the merge request are stored as the commit message. For example see https://gitlab.com/gitlab-org/gitlab-ce/commit/6c0db42951d65... This allows you to see any other things that were discussed. Hopefully any line comments were resolved with a commit (thus documenting them) or were based on a misunderstanding.

Thanks for the pricing tip, we'll fix it https://gitlab.com/gitlab-com/www-gitlab-com/issues/348

Re: GitFlow considered harmful

#96

Post by lotyrin »

adevine wrote: post #74
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 biggest disadvantage I see isn't in the branching model per se - it's that git itself does not record branch history. By "does not record branch history" I mean that branches are really just pointers to a specific commit in the commit history. However, git doesn't record where that branch pointed to IN THE PAST. So, when looking back in time and you look at a merge commit (say between a feature branch onto develo…

The convention is to make sure that the stable branch is the left parent, and the feature branch is the right, and that the merge commit log messages are decent (Gitb web UIs do this fairly decently by default). Now you can get a log of left-parent merge commits to see the log of features that shipped (or releases that shipped if you have multiple tiers of stability).

Re: GitFlow considered harmful

#97

Post by jrochkind1 »

Mithaldu wrote: post #89
jrochkind1 wrote: post #84

Earlier quoted context omitted.

I tend to agree. One exception I think is rebase on a feature branch. If you rebase a feature branch onto master before merging it into master, I think you can get a cleaner history while achieving the linear history the OP wants -- and in this isolated case, I think you aren't losing any useful context by making it seem the feature commits were all done right before merge into master. Maybe. I'm not actually sure, t…

People who love rebasing and linear history tend to see feature branches, even if pushed to a public repository, as private to their creator and maintainer and fair game for any sort of rebase. In fact, we do consider rebasing of feature branches mandatory.

The counter argument though is when your feature branch doesn't only have _one_ creator/maintainer. Mine often don't, especially on open source projects, two or three people can be working collaboratively, or others that aren't the lead on the feature can come in to make a helpful commit here or there.

And when one person rebases the feature branch it wreaks havoc for collaborators on the feature branch.

Which is why I limit my "rebasing is okay" on a feature branch to only _right before_ it's merged into master and then deleted. It still doesn't get rid of all the problems, but it gets rid of most of them.

Re: GitFlow considered harmful

#99

Post by pc86 »

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.

What would be an example where master differs from production?

Re: GitFlow considered harmful

#100

Post by sytse »

Mithaldu wrote: post #89
jrochkind1 wrote: post #84

Earlier quoted context omitted.

I tend to agree. One exception I think is rebase on a feature branch. If you rebase a feature branch onto master before merging it into master, I think you can get a cleaner history while achieving the linear history the OP wants -- and in this isolated case, I think you aren't losing any useful context by making it seem the feature commits were all done right before merge into master. Maybe. I'm not actually sure, t…

People who love rebasing and linear history tend to see feature branches, even if pushed to a public repository, as private to their creator and maintainer and fair game for any sort of rebase. In fact, we do consider rebasing of feature branches mandatory.

If it is pushed other people can cherry-pick, CI generates results and other people might push commits on the same branch (when using the same repo). We think pushing indicates you want to work in public. We even made a Work In Progress (WIP) function for it in GitLab http://doc.gitlab.com/ce/workflow/wip_merge_requests.html
Post reply on HN