5 ms·

Exactly this. Whatever you call your branching methodology, if they last too long that's when the fun stops. This article is full of bluster about how bad git

by danw1979 7y ago

Exactly this. Whatever you call your branching methodology, if they last too long that's when the fun stops. This article is full of bluster about how bad gitflow is, but very little actual reasoning why. I don't like the ceremony all that much, but its working really well at my current large corporate gig across thousands of repos and engineers.

cryptonector 7y ago
I have some long-lived branches lying around for work I only occasionally have time and energy to do. E.g., I've an "ALWAYS DEFERRED" feature patch for PostgreSQL I need to eventually finish. Every time I come back to it I've fallen thousands of commits behind, and neither a merge nor a rebase can save me, but a rebase bisection script I have does save me by identifying the one commit upstream, in order, that causes conflicts that I have to resolve manually, then resumes the rebase bisection. Specifically, the algorithm is something like this (not tested; I've a script I should publish): bisect_rebase() { local ultimate_target=$1 local target=$2 shift 2 b=$(git merge-base HEAD $target) while [[ $b != $(git rev-parse $target) ]]; do n2u=$(git log --oneline $b..$ultimate_target | wc -l) n=$(git log --oneline $b..$target | wc -l) # Try rebasing directly onto the target git rebase --onto $target $b && return 0 # If we have conflicts and rebased across just # one commit, stop here ((n2u == 1)) && return 1 if ((n == 1)); then echo "Fix conflicts and exit 0 to continue or 1 to stop" if $SHELL -i; then git rebase --continue return 0 else git rebase --abort return $? fi fi git rebase --abort bisect_rebase $ultimate_target $(git log -n $((n/2)) --pretty=%h $b..$target) done }
- jariel 7y ago
  That is the scariest script I have ever seen in my life. It makes me believe there is a real existential problem with git as a product.
  - cryptonector 7y ago
    I wrote it on the spot. The actual script is here: https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...
  - foobarian 7y ago
    The nice thing is that git is serverless, so you can clone a throwaway repo and run this sort of risky thing safely. It makes what's impossible in SVN possible, though maybe not easy.
    - jariel 7y ago
      ... unless someone scripts pushing and pulling. ... unless changes were not already pushed and therefore 'saved'. Git is inherently dangerous and overly complex - such a script shouldn't ever have to exist for so many reasons.
  - cryptonector 7y ago
    Oh get off your high horse. Git started as a collection of small programs and shell scripts, and as time went by more of those scripts became programs.
    - jariel 7y ago
      How it came to be is basically irrelevant when determining how materially useful it is, given all the bizarre artifacts of git. Nobody really seems to really have mastered it, most people seem to grasp only a subset, and there are so many potential pitfalls. It's a very powerful, raw technology that hasn't been properly productized, or rather, 'it works how Linus wants it to for his reasons' and everyone else just gets dragged along.
      - cryptonector 7y ago
        > Nobody really seems to really have mastered it You can speak for yourself. Don't speak for me or my colleagues.
- cryptonector 7y ago
  https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...
contractor8 7y ago
"Whatever you call your branching methodology, if they last too long that's when the fun stops." Doesn't git-flow explicitly keep a long lived branch around by design? The whole concept of having "develop" run in parallel to master is introducing a long lived branch. That's typically the branch that I'd always have the most trouble with.
- usrusr 7y ago
  That's assuming that there is anything going on on master at all. A gitflow master doesn't really count as a branch of it's just a permanent alias for the latest mainline release tag.
  - contractor8 7y ago
    Often when I encounter (startup) teams using this git-flow inspired strategy there definitely are things going on with master that shouldn't be. For example: Feature A is in staging ('develop'), but can't get into prod ('master') yet. However, the opposite is true of Feature B -- a customer needs it now and timelines get changed by sales or management (your largest customer needs it now). It conflicts with something in A and can't go into staging just yet (another team needs it). So that feature branch needs to go straight into master without hitting develop. The whole deployment infrastructure was designed on the (false) assumption that develop is always deployable to staging, and master to prod, rather than being able to quickly deploy and test feature branches at whim. So now we've diverged between master and develop a bit, and while we could still get our way back to a "clean" git-flow at this point pretty easily, if you're not careful this can keep compounding. I've seen it compound for months, and personally have wasted days trying to clean up conflicts that set in because teams I'm consulting for weren't careful. It's easy to have an inexperienced startup team make these git-flow based decisions early on, get stuck with them for some time, hit rapid growth, and then get themselves into a messy place. My point is sure, use it if you have pretty steady release and deploy schedules. But if you're deploying dozens of times per day you need to design your infra and CD strategy to handle it. Typically I've seen teams with fragile deploy strategies they've adopted due to assumptions they made from starting with git-flow. So why even do it? There are simpler strategies like GitHub Flow that force a team to design a deployment strategy that accepts that feature branches can be tested in a real environment, and master can always be delivered (or rolled back).

cryptonector 7y ago

I have some long-lived branches lying around for work I only occasionally have time and energy to do. E.g., I've an "ALWAYS DEFERRED" feature patch for PostgreSQL I need to eventually finish. Every time I come back to it I've fallen thousands of commits behind, and neither a merge nor a rebase can save me, but a rebase bisection script I have does save me by identifying the one commit upstream, in order, that causes conflicts that I have to resolve manually, then resumes the rebase bisection. Specifically, the algorithm is something like this (not tested; I've a script I should publish): bisect_rebase() { local ultimate_target=$1 local target=$2 shift 2 b=$(git merge-base HEAD $target) while [[ $b != $(git rev-parse $target) ]]; do n2u=$(git log --oneline $b..$ultimate_target | wc -l) n=$(git log --oneline $b..$target | wc -l) # Try rebasing directly onto the target git rebase --onto $target $b && return 0 # If we have conflicts and rebased across just # one commit, stop here ((n2u == 1)) && return 1 if ((n == 1)); then echo "Fix conflicts and exit 0 to continue or 1 to stop" if $SHELL -i; then git rebase --continue return 0 else git rebase --abort return $? fi fi git rebase --abort bisect_rebase $ultimate_target $(git log -n $((n/2)) --pretty=%h $b..$target) done }

jariel 7y ago
That is the scariest script I have ever seen in my life. It makes me believe there is a real existential problem with git as a product.
- cryptonector 7y ago
  I wrote it on the spot. The actual script is here: https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...
- foobarian 7y ago
  The nice thing is that git is serverless, so you can clone a throwaway repo and run this sort of risky thing safely. It makes what's impossible in SVN possible, though maybe not easy.
  - jariel 7y ago
    ... unless someone scripts pushing and pulling. ... unless changes were not already pushed and therefore 'saved'. Git is inherently dangerous and overly complex - such a script shouldn't ever have to exist for so many reasons.
- cryptonector 7y ago
  Oh get off your high horse. Git started as a collection of small programs and shell scripts, and as time went by more of those scripts became programs.
  - jariel 7y ago
    How it came to be is basically irrelevant when determining how materially useful it is, given all the bizarre artifacts of git. Nobody really seems to really have mastered it, most people seem to grasp only a subset, and there are so many potential pitfalls. It's a very powerful, raw technology that hasn't been properly productized, or rather, 'it works how Linus wants it to for his reasons' and everyone else just gets dragged along.
    - cryptonector 7y ago
      > Nobody really seems to really have mastered it You can speak for yourself. Don't speak for me or my colleagues.
cryptonector 7y ago
https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee6509c3526297 https://gist.github.com/nicowilliams/ea2fa2b445c2db50d2ee650...

contractor8 7y ago

"Whatever you call your branching methodology, if they last too long that's when the fun stops." Doesn't git-flow explicitly keep a long lived branch around by design? The whole concept of having "develop" run in parallel to master is introducing a long lived branch. That's typically the branch that I'd always have the most trouble with.

usrusr 7y ago
That's assuming that there is anything going on on master at all. A gitflow master doesn't really count as a branch of it's just a permanent alias for the latest mainline release tag.
- contractor8 7y ago
  Often when I encounter (startup) teams using this git-flow inspired strategy there definitely are things going on with master that shouldn't be. For example: Feature A is in staging ('develop'), but can't get into prod ('master') yet. However, the opposite is true of Feature B -- a customer needs it now and timelines get changed by sales or management (your largest customer needs it now). It conflicts with something in A and can't go into staging just yet (another team needs it). So that feature branch needs to go straight into master without hitting develop. The whole deployment infrastructure was designed on the (false) assumption that develop is always deployable to staging, and master to prod, rather than being able to quickly deploy and test feature branches at whim. So now we've diverged between master and develop a bit, and while we could still get our way back to a "clean" git-flow at this point pretty easily, if you're not careful this can keep compounding. I've seen it compound for months, and personally have wasted days trying to clean up conflicts that set in because teams I'm consulting for weren't careful. It's easy to have an inexperienced startup team make these git-flow based decisions early on, get stuck with them for some time, hit rapid growth, and then get themselves into a messy place. My point is sure, use it if you have pretty steady release and deploy schedules. But if you're deploying dozens of times per day you need to design your infra and CD strategy to handle it. Typically I've seen teams with fragile deploy strategies they've adopted due to assumptions they made from starting with git-flow. So why even do it? There are simpler strategies like GitHub Flow that force a team to design a deployment strategy that accepts that feature branches can be tested in a real environment, and master can always be delivered (or rolled back).