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

281–290 of 342 posts

Re: GitFlow considered harmful

#281

Post by antihero »

jkyle wrote: post #132
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.…

Say I create a feature branch, this is what a day's work might look like. 839a882 Fix bad code formatting [James Kyle] 6583660 Updated plugin paths for publish env [James Kyle] 847b8f3 First stab at a mobile friendly style. [James Kyle] a70d3f7 Added new articles, updated a couple. [James Kyle] b743ec3 format changes on article [James Kyle] 68231e7 Some udpates, added an article [James Kyle] 2a92c5e Added plugins to…

Is there a handy macro/script type thing that simplifies squashing a release branch and using the commit messages as bullet points (with the ability to edit out crap)?

Re: GitFlow considered harmful

#282

Post by hayd »

sorbits wrote: post #250
clinta wrote: post #247

Earlier quoted context omitted.

Why do you need to rewrite? If a pull request is not completed, you can continue to push it and the PR is updated to pull the latest commit.

I will get pull requests where later commits fix bugs introduced in former commits. I generally ask people to rewrite such PRs, as I’m not going to pull known buggy commits into master, even if they are followed by fixes. That is just noise. It might also be that some commits in the PR has changed tabs to spaces or vice versa.

I think the point was: if you have a PR with two commits, you can squash it to a single commit and force push. This will update the PR to just have the single commit. (Similarly with a rebase.)

Re: GitFlow considered harmful

#283

Post by bksta »

slavik81 wrote: post #227
mikeash wrote: post #149

Earlier quoted context omitted.

I'm talking about both public and private history. It's far more beneficial to just not make commits like "Derp" or "Whoops" in the first place. Think about your commits and your commit messages as you make them . No, you won't get it right all the time. And that's OK; nobody is perfect, and your history can reflect that you're not perfect. But if you're editing your commit history to fix idiotic commit messages, you…

One of the things I like about git is that I can make bad commits and fix them later. If I'm working on one feature and I'm interrupted by another task, I can commit "wip - blah", then check out a different branch and work on that. When I go back, I pick up exactly where I left off, and amend the half-finished commit into something that actually makes sense before pushing it out to the rest of the team. In the past,…

"git stash" was created for this purpose

Re: GitFlow considered harmful

#284

Post by hayd »

barrkel wrote: post #171
tomphoolery wrote: post #148

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

Whilst this is occasionally useful, it's best avoided in my opinion as it's incredibly difficult to review a merge commit (especially a large merge commit).

(Most of the time I'd advocate, if you have to do larger project branches, either merging work in piecemeal asap e.g. hidden behind a flag or whatever, or keeping work in new files so that merge conflicts are kept to a minimum.)

Re: GitFlow considered harmful

#285

Post by hayd »

gingerlime wrote: post #80
realityking wrote: post #49

Earlier quoted context omitted.

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

Re: GitFlow considered harmful

#286

Post by edmccard »

mikeash wrote: post #211
jasode wrote: post #201

Earlier quoted context omitted.

>, but if you're fearful of breaking builds, then once you did make such a mistake, the ability to go back and rewrite it would surely look pretty good. But I was trying to emphasize that Git's "mental model" eases the burden breaking the build. If everyone buys into the concept that "git commits" are just another lightweight form of "Ctrl+S", we would expect for programmers' private branches to sometimes have broken…

When you say it's another form of ^S, how often are we talking here? I reflexively ^S every couple of words, are you literally talking about committing every couple of words? Every few lines? Less? What's the purpose committing more often than logical chunks of code which can be considered in some sense "done"?

>I reflexively ^S every couple of words...

Why not just decrease the autosave interval in your editor :)

>What's the purpose committing more often than logical chunks of code which can be considered in some sense "done"?

There are different degrees of "doneness". For example, (1) code that isn't finished but you don't want to lose it if the power goes out, (2) code that you're not sure if you're going to keep, but you'd like to be able to refer back to it even if you later decide to change it, (3) code that completely accomplishes its purpose in a logical and coherent manner.

I use "Ctrl-S" for (1), "git commit" to a local branch for (2), and "git rebase/git push" for (3). Maybe I'm just a sloppy programmer, but my workflow often involves writing some code, making certain changes, then realizing that what I really need is the previous version but with different changes. So for me, frequent commits on a local branch have replaced frequent saves under different filenames (foo.c, foo_old.c, foo_tried_it_this_way.c)

Re: GitFlow considered harmful

#287

Post by INTPnerd »

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

Everything about git is about managing a useful history. Otherwise it would be a history of every keystroke or at least every file write. Instead you write some code until you feel you have enough to make a useful commit (you will have to come up with your own idea of what represents a useful commit), commit all those changes together as a single commit (thereby losing history), and come up with a useful description of all those changes. Managing an already created commit is just a further extension of this idea. You can use what you learned from from your experience of coding, testing, and committing to change your commit history to be even more useful. Of course things can go wrong if you are changing the history of a branch that others have cloned or branched off of.

Re: GitFlow considered harmful

#288

Post by goostavos »

sopooneo wrote: post #234
aoeuasdf1 wrote: post #205

Earlier quoted context omitted.

Ok, that makes sense... but then why bother pushing the branch in the first place?

We have a rule that you never go home at night without pushing your work, even if it's garbage. Put it in a super-short-term feature branch if needed, and push that, but don't leave it imprisoned on your machine.

There are people who follow this rule, and there are people that think disk failures are what happen to other people.

Few things sting as bad as loosing hours or days worth of work.

Re: GitFlow considered harmful

#289

Post by mikeash »

mbesto wrote: post #252
aoeuasdf1 wrote: post #205

Earlier quoted context omitted.

Ok, that makes sense... but then why bother pushing the branch in the first place?

Immediate backup (I hope I'm not alone in saying this...)

I kinda hope you are, because backup and source control really should be separate functions. Obviously your source control repository should be backed up, and pushing stuff into it acts to create a backup, but you really should have a separate backup system at work as well, to cover unpushed code as well as all the other useful info contained on your computer.

Re: GitFlow considered harmful

#290

Post by recursive »

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

> If I have to stop and THINK about the VCS every time I use it, or if it gives me some obscure "PC LOAD LETTER" type of response I'm sorry, there is no kind way to say this without spending too much time i don't have. You're making the same kind of argument i am hearing from older people in my family about newer hardware (tvs, phones, etc.). You see an initial learning curve and falsely assume that this curve will n…

I've spent more time learning git than I have spent learning all other VCS combined, of which there have been at least a few in my history. My mastery of git is significantly less than that of any other VCS I've used. Less powerful VCS are easier to use, and that can be a feature.
Post reply on HN