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

311–320 of 342 posts

Re: GitFlow considered harmful

#311

Post by tokenizerrr »

Mithaldu wrote: post #310
tokenizerrr wrote: post #308

Earlier quoted context omitted.

Are you serious? I was being polite and posted a question asking for some constructive feedback. I got some of this, then Mithaldu went off the deep-end and decided to start ridiculing me and tell me how he'd avoid the company I work at because of the questions I'm asking. And now you're saying that I'm the one crossing a line here? Seriously? I just re-read the guidelines, which did I break? The only one I can imagi…

It wasn't your questions that bothered me, but your ideas expressed in these posts: https://news.ycombinator.com/item?id=9744910 https://news.ycombinator.com/item?id=9744929 Your initial question was perfectly fine to me. Further, while i think HN is inconsistent at best in how it applies its rules², i realize that dang does have a point and i could've dug further with questions, to see if your mind could be changed.…

Sorry, but when you react like the way you did I simply lose any interest in discussing the matter with you any further. Frankly it also makes you lose credibility in my book; if you cannot manage to have a polite conversation where you disagree with someone then it paints a picture of someone who yells and walks away whenever someone disagrees with them. A person like that may believe they are right, but if they can't properly discuss things, how would they know? So why should I trust them? Not saying that this interpretation is accurate or anything, that's just how your posts came off and why I wasn't interested in further discussing the matter with you and reacted the way I did.

But very well, as long as we can keep things polite:

There exists a possibility you misinterpreted my intent. I am talking about the following scenario:

* Feature branch is written by a developer, has been tested (not as much as they'd like, because deadlines) and it is merged into master

* Master branch is made publicly available, CI builds from it, and builds wind up in production

* Some time passes, eventually a critical bug is uncovered in the code from the feature branch. This is bad and should have been caught earlier, but it didn't, and shit happens.

* Work starts on a fix as soon as the developer resources are available. In the meantime the code from that feature branch should be "disabled" so the product remains functional in the meantime.

So what has worked well for us is reverting the merge commit(s) where the feature branch is merged into master. This commit is given a descriptive commit message and we actually appreciate there being a mark in the revision history about this.

We have dozens of these projects for different customers, and less than a dozen developers. Rewriting the history of the master branch would result in chaos as every developer gets to merge their own feature branch into master.

Are you still recoiling in horror? If so, feel free to elaborate as to why and how you would do this better.

Re: GitFlow considered harmful

#312

Post by Mithaldu »

tokenizerrr wrote: post #311
Mithaldu wrote: post #310

Earlier quoted context omitted.

It wasn't your questions that bothered me, but your ideas expressed in these posts: https://news.ycombinator.com/item?id=9744910 https://news.ycombinator.com/item?id=9744929 Your initial question was perfectly fine to me. Further, while i think HN is inconsistent at best in how it applies its rules², i realize that dang does have a point and i could've dug further with questions, to see if your mind could be changed.…

Sorry, but when you react like the way you did I simply lose any interest in discussing the matter with you any further. Frankly it also makes you lose credibility in my book; if you cannot manage to have a polite conversation where you disagree with someone then it paints a picture of someone who yells and walks away whenever someone disagrees with them. A person like that may believe they are right, but if they can…

Cheers. I'm pleasantly surprised.

Sadly i don't have mounds of time right now to write bigger answers, but i first need to figure out what your knowledge is, because we're not quite on the same page yet.

> every developer gets to merge their own feature branch into master.

Are you sure you wanted to say merge? If the master branch is rewritten into a new branch, feature branches on it would need to be rebased normally.

Is there a reason that you're saying "every developer gets to"? Normally they'd only need to rebase when they wish to integrate it back into master anyhow, which is likely to be conflict-free if they didn't rely on the feature, and also likely to be conflict-free if they wait until you've re-added the feature in a fixed state. And if they decide to rebase before you re-add it, then they'd have to deal with those conflicts exactly the same as if they'd merge before your revert-revert.

Do your developers do the SVN thing of continually merging master into their feature branch? Typically that is a bad habit which should be replaced with rebases of the feature branch.

Why do you care if history gets rewritten? Because you fear it would create more work, or because you consider history inviolable.

> we actually appreciate there being a mark in the revision history about this.

I think tags with descriptions would serve the same purpose. Do you see issues with that?

Re: GitFlow considered harmful

#313

Post by tokenizerrr »

Mithaldu wrote: post #312
tokenizerrr wrote: post #311

Earlier quoted context omitted.

Sorry, but when you react like the way you did I simply lose any interest in discussing the matter with you any further. Frankly it also makes you lose credibility in my book; if you cannot manage to have a polite conversation where you disagree with someone then it paints a picture of someone who yells and walks away whenever someone disagrees with them. A person like that may believe they are right, but if they can…

Cheers. I'm pleasantly surprised. Sadly i don't have mounds of time right now to write bigger answers, but i first need to figure out what your knowledge is, because we're not quite on the same page yet. > every developer gets to merge their own feature branch into master. Are you sure you wanted to say merge? If the master branch is rewritten into a new branch, feature branches on it would need to be rebased normall…

> Are you sure you wanted to say merge? If the master branch is rewritten into a new branch, feature branches on it would need to be rebased normally.

Yes. The way we currently do things is keeping things as simple as possible for everyone, even if this doesn't produce the prettiest history. A developer first creates their feature branch based off of master, commits several times to this feature branch, tests it and possibly asks for review from a coworker and then they merge this feature branch into master using --no-ff, always creating a merge commit.

It's possible there have been commits to master since they based off of it. If so, they will resolve this in the merge. I do think it would be better if feature branches got rebased prior to merging onto master so they can be tested in this state as well but this is currently not how things are done (it is not up to me). Though that could create issues if there's multiple developers collaborating on a feature branch and they do not communicate properly.

The reason I said "every developer gets to" is that in larger projects (which also usually use gerrit, which do not) I've seen that there are usually a select few people in charge of merging the feature branches into master, instead of everyone getting to merge as they see fit.

My view on rewriting history is that it should not happen on shared branches as this will surely lead to issues where one of the developers does not do the entire 'fetch rebase merge' dance correctly, or works directly on master. We also contract some work out to external agencies and their git usage is usually absymal, and I am not in the position to correct or influence any of that.

> I think tags with descriptions would serve the same purpose. Do you see issues with that?

I'm not sure how the tags with descriptions would help with easily rolling back all the changes introduced through a feature branch, but maybe I'm missing something.

Re: GitFlow considered harmful

#314

Post by Mithaldu »

tokenizerrr wrote: post #313
Mithaldu wrote: post #312

Earlier quoted context omitted.

Cheers. I'm pleasantly surprised. Sadly i don't have mounds of time right now to write bigger answers, but i first need to figure out what your knowledge is, because we're not quite on the same page yet. > every developer gets to merge their own feature branch into master. Are you sure you wanted to say merge? If the master branch is rewritten into a new branch, feature branches on it would need to be rebased normall…

> Are you sure you wanted to say merge? If the master branch is rewritten into a new branch, feature branches on it would need to be rebased normally. Yes. The way we currently do things is keeping things as simple as possible for everyone, even if this doesn't produce the prettiest history. A developer first creates their feature branch based off of master, commits several times to this feature branch, tests it and…

Merging feature branches off of one branch that was rewritten into a new one into the new one is nothing anybody would ever do or recommend. Rebasing is a requirement here, and truthfully an operation with less mental overhead, since it's actually just "copy all of those commits over to here, then put the branch marker at the end of the new copy".

It kind of sounds to me as if you're saying "i don't want my developers to not learn rebase because it's easier if they learn a little less". Is that a correct understanding? If so, then you're trading a little upfront work for a lot of cleanup work later on.

> My view on rewriting history is that it should not happen on shared branches

Depends on how shared they are and how big the fuck-up is. Everything is relative.

> as this will surely lead to issues where one of the developers does not do the entire 'fetch rebase merge' dance correctly

There should not be any merge involved there. See first paragraph.

> or works directly on master.

That developer gets a notice to get his shit together and gets fired if he persists. This is teamwork, not cowboy work.

> I'm not sure how the tags with descriptions would help with easily rolling back

They don't. They help with marking places where old broken branches were abandoned and marking places where their new counterparts were reinstated.

Lastly:

> it is not up to me

If it's not up to you, and they'd not be willing to listen then the conversation is moot and your org is broken. You can't wedge one small part of a rebase-based workflow into a larger workflow that pretends git is just SVN with a different syntax.

I can tell you how to do everything correctly and how it will actually make things nice and smooth, but if everything is not an option, then a little can't be applied to your situation.

Re: GitFlow considered harmful

#315

Post by gingerlime »

jes5199 wrote: post #260
gingerlime wrote: post #80

Earlier quoted context omitted.

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

when you look at the PR in github it doesn't look obvious that some of the commits are bad?

The commits aren't bad as such, just noisy, typically. Github gives you a nice diff of the whole branch against master, so we normally don't pay attention to individual commits. We look at the change as a whole before merging it.

There is an indicator for the number of commits and you can view each one individually, but somehow it's so easy to forget.

Re: GitFlow considered harmful

#316

Post by gingerlime »

kansface wrote: post #230
gingerlime wrote: post #80

Earlier quoted context omitted.

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

Stop merging from Github?

Yes, that's one possible solution, but feels like we're punishing ourselves for every merge for the sake of avoiding a reasonably-rare issue. We're reviewing PRs on github, so it's much more convenient to merge them on the spot.

Re: GitFlow considered harmful

#317

Post by nsfyn55 »

jes5199 wrote: post #270
nsfyn55 wrote: post #102

I have had this ideological debate about "fast forwarding" more times that I can count. I agree with the author "no-ff" is silly. I've been working on professional software teams for over a decade. When I encountered fast forwarding/rebasing it was absolutely a breath of fresh air. I've been using git now for 5 years and I have not encountered a single instance where using either of these tools has presented any sort…

no-ff is useful when you need to revert the whole merge - the merge commit delimits the boundaries of what used to be a separate branch. If you fast-forward, then you have to use your human brain to figure out how many commits to revert and when you're reacting to "augh I just broke master by adding these 12 commits" you might make a mistake.

Yeah that's why you squash your 12 commits into a single commit that represents the deliverable.

This is my point I find the 12 commits to be unnecessary. I've never been burned by squashing. The only arguments I've heard against it are ideological(you're destroying history, etc.)

Re: GitFlow considered harmful

#318

Post by gingerlime »

hayd wrote: post #285
gingerlime wrote: post #80

Earlier quoted context omitted.

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

I recommend regularly updating your branch of master via fast-forward. That way if you are working with a slightly different git history, git will complain loudly (refuse to update). This also has the benefit of complaining if someone else has force pushed (changed history / removed commits) to upstream/master. Catch it early. https://leanpub.com/sanegit (I consult/train on this in SF/Bay area.)

I'm not sure I understand how this will solve my problem to be honest, and unfortunately it's not something we would seek to hire a consultant for.

Re: GitFlow considered harmful

#319

Post by jes5199 »

nsfyn55 wrote: post #317
jes5199 wrote: post #270

Earlier quoted context omitted.

no-ff is useful when you need to revert the whole merge - the merge commit delimits the boundaries of what used to be a separate branch. If you fast-forward, then you have to use your human brain to figure out how many commits to revert and when you're reacting to "augh I just broke master by adding these 12 commits" you might make a mistake.

Yeah that's why you squash your 12 commits into a single commit that represents the deliverable. This is my point I find the 12 commits to be unnecessary. I've never been burned by squashing. The only arguments I've heard against it are ideological(you're destroying history, etc.)

oh! Well, I like reading many little diffs more than I like reading a few big diffs, but the distinction is purely aesthetic. A team should try to agree on an aesthetic, but otherwise, ::shrug::.

Re: GitFlow considered harmful

#320

Post by nhaehnle »

twic wrote: post #306
nhaehnle wrote: post #237

Earlier quoted context omitted.

Running test before committing locally adds a lot of friction. It often happens to me that I work on a feature in component A, and in doing so, realize that it would be great to have some additional feature in component B (or perhaps there's a bug that needs to be fixed). As long as the components are logically separate, it's usually a good idea to make those changes in separate commits. While you can do that using s…

When you come up with the idea for a feature in component B, or a bug to fix, rather than implementing it, make a note of it, and carry on with what you were doing. Once that's done and committed, you can go back to the other thing. That way, you end up with coherent separate commits, that you can test individually as you make them, without having to rewrite history. Not only that, but you can give each commit your f…

It's possible that we just have different styles of working.

Still, to clarify: Not all, but some of the situations I have in mind are situation where the changes in component A cannot possibly work without the changes in component B.

So an alternative workflow could rather be: Stash all your changes made so far, then do the changes in component B, commit, and then reapply the stashed changes in component A. That's something I've tried in the past, and it can work. However, it has downsides as well. In particular, having the in-progress changes in component A around actually helps by providing the context to guide the changes in component B. So you avoid situations where, after you've continued working on component A, you realize that there's still something missing to component B after all (which may be something as silly as an incorrect const-qualifier).

It's also possible that our preferences depend on the kind of projects we're working on. What I've described is something that has turned out to work well for me on a large C++ code base, where being able to compile the work-in-progress state for both components simultaneously is very useful to catch the kind of problems like incorrect const-qualifiers I've mentioned before.

I could imagine that on a different type of project your way works just as well. For example, in a project where unit testing is applicable and development policy, so that you'd write separate tests for your changes to component B anyway, being able to co-test the work-in-progress state across components is not as important because you're already testing via unit tests.

Post reply on HN