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

171–180 of 342 posts

Re: GitFlow considered harmful

#171

Post by barrkel »

tomphoolery wrote: post #148
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.…

> 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. I disagree, and it's actually impossible not to use it. Rebase rewrites history. If you have a long-running feature branch you need to merge back into master, you have to rebase it against the current master. There'…

If you have a long-running feature branch you need to merge back into master, you have to rebase it against the current master. There's really no other choice.

Yes you do. Merge master into your branch. Rebasing long-running branches is a nightmare, because every diff you replay will probably result in a conflict, and if you have hundreds of commits, you could be there for several days rebasing. Merges, even massive merges, generally don't take more than a few hours. All project size dependent of course, but the ratio of work is about right: 5-10x more work for a rebase over a commit.

Re: GitFlow considered harmful

#172

Post by Jacqued »

wylee wrote: post #134
phs2501 wrote: post #110

Earlier quoted context omitted.

The point of rebasing for clarity, IMHO, is to take what might be a large, unorganized commit or commits (i.e. the result of a few hours good hacking) and turning it into a coherent story of how that feature is implemented. This means splitting it into commits (which change one thing), giving them good commit messages (describing the one thing and its effects), and putting them in the right order. Rather than hiding…

I agree with you, but only for local commits that haven't been pushed to a shared repo. Rewriting local history seems no different than rewriting code in your editor. Rewriting shared history is (almost) always bad.

We've been fine using rebase on already pushed branches. This comes from the understanding that a feature branch belongs to one developer, ever, and that no one else is supposed to work off of it (or at their own peril).

Everyone knows that it's "my branch" and that they're absolutely not supposed to use it for anything until it's merged back into master or whatever authoritative branch.

Re: GitFlow considered harmful

#173

Post by Joeri »

barrkel wrote: post #155
ams6110 wrote: post #121

Earlier quoted context omitted.

Disclosure up front, I don't really use git myself. I have tried it and found it to be too confusing. I liked svn and these days use hg. I also tend to work on mostly solo and small projects. However in my observation I have found that more than any other revision control system I have used, the person ultimately responsible for the code spends far more time cleaning up history and recovering from developer mistakes…

FWIW, I've spent far more time thinking about svn than I ever spent thinking about git. Specifically, porting changes between multiple branches in svn was a nightmare. E.g. if you have three different branches (two releases and a develop), and you need to make the same bugfix on all of them - extremely unpleasant. I ended up writing my own diff/patch management system to keep track of bug fix patches, so that I could…

My two cents is that i haven't found it difficult to merge between branches myself. I'll open up a diff view of the commit(s) i want to merge, and then merge them branch-to-branch and file-to-file using a two-way merge tool, using the diff as a guide.

Re: GitFlow considered harmful

#174

Post by sytse »

Mithaldu wrote: post #94
sytse wrote: post #83

Earlier quoted context omitted.

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

Parent was deleted.

Re: GitFlow considered harmful

#175

Post by lgp171188 »

sytse wrote: post #117
darylteo wrote: post #98

Curious here: has anyone tried using GitLab + forks to replace development branches? Would it needlessly overcomplicated?

You can do it but at GitLab we advise against it if you can avoid it. Many things become harder, for example it is more work to to link merge requests to issues and you can't push a commit to help a person without them giving you access first.

If you are using the Integration-Manager workflow (which GitLab doesn't support as well as Bitbucket or GitHub), all the members of a team have read access to all the repositories and forks in the team namespace. That means the owner of a developer branch fork can always read the repo of another contributor and pull the changes.

Re: GitFlow considered harmful

#176

Post by nevi-me »

mikeash wrote: post #166
nevi-me wrote: post #162

Earlier quoted context omitted.

Can't reply to mikeash below, but I also have a comment. I've burnt myself a few times where I committed something and pushed to my remote repo, only to realise that I shouldn't have. What I've taken from my errors is that I no longer push single commits until I'm at least done with what I'm doing (I use GitFlow btw). It's easier for such things to happen in languages where you don't need to build your project (looki…

Even in a language like JavaScript, you're at least running your new code before you commit, surely. As for a fix which introduces a regression somewhere else, that seems like exactly the sort of history you'd want to capture in source control. "Fixed X." "The fix for X broke Y, which is now fixed." This is much more informative than a single "Fixed X." which only includes the final state. The fact that a fix for X c…

Yes, I run it, but if out of the possible 5'000 combinations that I go through when searching (https://rwt.to, essentially an A-B public transit planner, https://movinggauteng.co.za - data behind the planner) one of them breaks, it becomes difficult to spot errors until a few days later at times.

I could write something that does searches for as many combinations as possible, but I'm at the point where the cost of getting an error is better than spending a day where I can't work on my code because tests are running (the data changes regularly). That day's often a weekend where I've got a small window of time to work on my hobby.

On your last point, I often end up being detailed on my commits where I can fiddle with the history before pushing to remote, so I still end up capturing what happened in SC.

I'd really love a suggestion on how I could get around this, it would help me improve (I'm an accountant by profession, but do some SAS, R, Python, JS etc. as part of my ever-changing job).

Re: GitFlow considered harmful

#177

Post by sytse »

lgp171188 wrote: post #175
sytse wrote: post #117

Earlier quoted context omitted.

You can do it but at GitLab we advise against it if you can avoid it. Many things become harder, for example it is more work to to link merge requests to issues and you can't push a commit to help a person without them giving you access first.

If you are using the Integration-Manager workflow (which GitLab doesn't support as well as Bitbucket or GitHub), all the members of a team have read access to all the repositories and forks in the team namespace. That means the owner of a developer branch fork can always read the repo of another contributor and pull the changes.

Please let me know what you think we should improve to support that workflow better.

Anyway, I think my examples are still valid, it is harder to mention issues and you can't push (write) commits on forks since your have read permissions.

Re: GitFlow considered harmful

#178

Post by Touche »

madeofpalk wrote: post #114
Touche wrote: post #81

Earlier quoted context omitted.

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…

I think the idea is that the branches cascade. You would never create new commits directly into release or master, the flow would only ever be develop > release > master, thus making merge commits and conflicts impossible.

That doesn't work in practice, you are always going to need to "fast-track" a bug fix, skipping develop (which has code you don't want to deploy).

Re: GitFlow considered harmful

#179

Post by scottious »

I don't see why there has to be "this is harmful" and "this is a better way".

I've used all kinds of branching models... I've used just a master branch and you commit directly to master. I've used full git-flow.

I think the branching model you use is dependent on the people and the project. But really no matter which model I've used it seemed to me to be fine... And if it wasn't fine, we extended it to meet our requirements.

Re: GitFlow considered harmful

#180

Post by JanezStupar »

nsfyn55 wrote: post #145
JanezStupar wrote: post #128

Earlier quoted context omitted.

Because you do not need something, then it has to be useless. > From what I can tell no-ff exists to satisfy the aesthetic preference of your local team pedant. Incredible irony.

well can you provide the killer use case that none of us can live without? I mean its certainly possible that in some tiny fraction of cases I might say "man I could fix this a lot easier if I had the merge commit" its just in the 10,000's of examples that form my experience I haven't stepped on that particularly landmine yet. Even with that said, my development philosophy compels me to choose "Simplicity over Comple…

The killer use case for me is getting to figure out how and when something happened.

Also merging two branches that tend to touch upon same modules but are not kept in sync all the time (due to whatever reasons) is a lot simpler when you use --no-ff.

You say that these properties are bullshit, but I found them invaluable when fixing bugs and architectural defects and where it was important to find out when and how the bug or a behaviour occurred. And funny that you mention accountants and auditors. Because being able to do forensics more easily on the codebases that I worked on has saved me and my clients many hours and gray hair. And I have found myself in situations where

I can live without --no-ff, I can live without git even. There is plenty of people out there not using any kind of source control and they are living just fine.

Your last paragraph is a nice example of psychological projection. If you weren't so narrow minded you could have used your energy to learn something.

Myself I use --no-ff because it fits the kind of work I do very well. I haven't lost a minute of sleep or time over its deficiencies. And I am pretty certain that I spend a whole lot less time fiddling with git than people who advocate "agressive rebasing".

I do admit you have some merit in pointing out how bad a git history looks when littered with merge commits for single commit branches. But then, this is pretty easy to fix. Just use a fucking vanilla merge, or indeed a rebase when it fits the problem. Another way to work around the bad aspects of --no-ff approach is by using a better git history explorer.

Post reply on HN