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

71–80 of 342 posts

Re: GitFlow considered harmful

#71

Post by solutionyogi »

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…

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. Merge the release branch in to master.

This is exactly what we do at my current workplace where we have 4 developers working on changes with different release schedule.

Re: GitFlow considered harmful

#72

Post by mikeash »

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.

How are you going to find out when a bug was introduced, or see the context in which a particular bit of code was written, when you may have erased what actually happened and replaced it with a whitewashed version? What is the point of having commits in your repository which represent a state that the code was never actually in?

It always feels to me like people just being image-conscious. Some programmers really want to come across as careful, conscientious, thoughtful programmers, but can't actually accomplish it, so instead they do the usual mess, try to clean it up, then go back and make it look like the code was always clean. It doesn't actually help anything, it just makes them look better. The stuff about nonlinear history being harder to read is just rationalization.

Re: GitFlow considered harmful

#73

Post by tokenizerrr »

Mithaldu wrote: post #68
tokenizerrr wrote: post #60

Earlier quoted context omitted.

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.

Wow, way to be literally the opposite of constructive. Grow up.

Re: GitFlow considered harmful

#74

Post by adevine »

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 development), you can't immediately tell which of the two paths BEFORE that merge commit was originally the feature branch, and which was originally the feature branch. A great example of this is looking at the network view in github, which can turn into a confusing mess because how github decides to color the branch paths is NOT necessarily how those branch paths existed in the past.

If anyone has a solution to this problem please share!

Re: GitFlow considered harmful

#75

Post by Eridrus »

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…

Does having a lower level of quality on develop hinder your ability to actually release code?

We have one particular repo at work that is just a pain in the ass to work with (Typescript analytics code that has to be backwards compatible to about forever), and we've pretty much abandoned the develop branch since releases got held up due to bugs in less important features that had been merged in without comprehensive testing. Pretty much everything now gets tested extensively on a feature branch and then gets merged directly into a release branch.

We might have swung a little too far in the other direction, I'm thinking we want to at least merge well tested bits back onto develop, but at least we can release the features that are actually done and cut those that are still having issues without having to do any major git surgery.

Re: GitFlow considered harmful

#76

Post by Mithaldu »

tokenizerrr wrote: post #73
Mithaldu wrote: post #68

Earlier quoted context omitted.

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.

Wow, way to be literally the opposite of constructive. Grow up.

We obviously don't see eye to eye. The only thing left is to agree to disagree. And i meant the thing about the company.

Re: GitFlow considered harmful

#77

Post by aidos »

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

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.

Re: GitFlow considered harmful

#78

Post by sytse »

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

Re: GitFlow considered harmful

#79

Post by ionforce »

pskocik wrote: post #26

I think he makes a valid point about how it's not necessary to have both develop and master if you use tags. On the other hand, I think the `--no-ff` merges is what git-flow got right. The separation of features into their own branches is useful. It's basically about grouping related commits together. You can always render the history in a way that looks prettier and even if you can't--the history doesn't need to loo…

I disagree with you that the history doesn't look pretty.

Have you not found the ability to investigate/audit bugs hindered by non-linear histories?

Re: GitFlow considered harmful

#80

Post by gingerlime »

realityking wrote: post #49
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.

slightly OT, but I wonder if anyone has an answer for this.

We use feature branches and rebase before merging to master (mostly for the reason stated above - keep things clean and treating the branch as a single logical unit, not caring about higher-resolution history within the branch).

However, some times, especially since we typically merge on Github from a PR, it's easy to forget to rebase, or notice that there are more commits. So our history is mostly clean, but occasionally contain some "messy" commits.

I know we can reset master, but it feels a bit too risky compared to living with a bit of noise when mistakes happen.

Anyone knows of some way to prevent / alert / notify or otherwise help us avoid this rather common mistake before it happens?

Post reply on HN