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

81–90 of 342 posts

Re: GitFlow considered harmful

#81

Post by Touche »

Alexandervn wrote: post #48
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…

The problem with having too many eternal branches is that they quickly become unmergeable. The nice thing about feature branches is that it's the author's responsibility to make it mergeable. But if you having a bunch of eternal branches none of which are "owned" by one person, when it comes time to merge them and there's dozens of merge conflicts there's not one person that can set down and know what the correct fix is for all of them.

Re: GitFlow considered harmful

#83

Post by sytse »

solutionyogi wrote: post #66
tehbeard wrote: post #62

Earlier quoted context omitted.

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.

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

Re: GitFlow considered harmful

#84

Post by jrochkind1 »

mikeash wrote: post #72
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…

The obsession of git users with rewriting history has always puzzled me. I like that the feature exists, because it is very occasionally useful, but it's one of those things you should almost never use. The whole point of history is to have a record of what happened. If you're going around and changing it, then you no longer have a record of what happened, but a record of what you kind of wish had actually happened.…

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, to be honest what's a good idea with git history, this included. Feedback welcome.

Re: GitFlow considered harmful

#85

Post by maratd »

BillinghamJ wrote: post #67
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. 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 other hand, should always be stable and rock solid. You can then have production servers that always pull master automatically, and staging servers that always pull develop automatically.

I've worked on multiple teams this way it works out quite well.

Re: GitFlow considered harmful

#86

Post by solutionyogi »

aidos wrote: post #77
solutionyogi wrote: post #47

Earlier quoted context omitted.

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

I don't think that's true. If you have a feature branch with a number of changes in the same place, rebasing on to a branch that also changes in the same spot means you need to fix all of the related commits during the rebase. If it's a big feature that could end up being a huge task. I may be wrong about that as I'm no git guru.

True. You do have to fix all the true conflicts. But you have to do it only once. If you merge your master, you have to resolve conflicts every time you merge from the master. git rerere could be potentially useful here.

Even more importantly rebase allows you to resolve conflict at individual commit level. During conflict, you can see the exact commit that is causing it, making it much easier to resolve it.

See: http://jeffkreeftmeijer.com/2010/the-magical-and-not-harmful...

Re: GitFlow considered harmful

#87

Post by Mithaldu »

sytse wrote: post #78
mikeash wrote: post #72

Earlier quoted context omitted.

The obsession of git users with rewriting history has always puzzled me. I like that the feature exists, because it is very occasionally useful, but it's one of those things you should almost never use. The whole point of history is to have a record of what happened. If you're going around and changing it, then you no longer have a record of what happened, but a record of what you kind of wish had actually happened.…

I totally agree with you, I don't get it either. My only explanation is that as a programmer you are trained to write clean and understandable code. I also try to apply this to my commit messages (with varying results). But rewriting history to make everything look clean and simple is the wrong this to do. The messier your history is the more likely you'll need to retrace your steps (and CI results) at some point. It…

> It is mostly people coming from SVN and only running CI on the trunk branch that favor the rewriting approach. It might be hard to let go.

You're being ridiculously prejudiced and jumping to conclusions AND throwing out judgements on things that by your own admission ("I don't get it either.") you do not understand.

Please realize that the correct response in such a case is not to double down, but to engage in a dialogue so you may reach understanding of which factors you're unaware of or they're unaware of, that create the difference in stance. (And no, you can't expect the other side to initiate the dialogue. The way you are talking you present an image of someone singularly uninterested in dialogue, even if that may be unintentional.)

Re: GitFlow considered harmful

#88

Post by sytse »

Mithaldu wrote: post #51
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…

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.

Re: GitFlow considered harmful

#89

Post by Mithaldu »

jrochkind1 wrote: post #84
mikeash wrote: post #72

Earlier quoted context omitted.

The obsession of git users with rewriting history has always puzzled me. I like that the feature exists, because it is very occasionally useful, but it's one of those things you should almost never use. The whole point of history is to have a record of what happened. If you're going around and changing it, then you no longer have a record of what happened, but a record of what you kind of wish had actually happened.…

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.

Re: GitFlow considered harmful

#90

Post by jrochkind1 »

solutionyogi wrote: post #71
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…

If you need independent release cycle for Feature A / Feature B, you adjust GitFlow by basing all branches (feature/release/hotfix) from the master. Let's say next release is Release-1.10 1. We merge Feature A and Feature B to it. 2. Feature A is tested and ready to be deployed. Feature B is not. 3. You either revert Feature B commit OR re-create the release branch with only Feature A. 4. Deploy the release branch. 5…

And then do you need the 'develop' branch at all? If not, you're describing something similar to what OP is.
Post reply on HN