4 ms·

The perennial problem with discussions of Git workflows is the underlying belief that there exists, if only we can find it, the One True Workflow. This belief

The perennial problem with discussions of Git workflows is the underlying belief that there exists, if only we can find it, the One True Workflow. This belief is false. Git is a powerful, general tool that lends itself to just about any workflow imaginable and, because of its adaptability, different teams will naturally converge on different Git workflows as "right." These teams, however, have a hard time imagining and thus accounting for the conditions and preferences of other teams, and end up advocating for their workflows as the best workflow. Thus we end up with strongly held and yet contradictory beliefs. Some people claim that "rebasing is a bad habit: it destroys history" while others claim that "rebasing is a good habit: it prevents repo cruft." Who is right? It depends on your preferences, which ought to reflect your team, your project, and your company culture. For my projects, I prefer to edit my work into tight, clean commits before merging them into the mainline branch. That's because I value the logical story of my software's evolution and not the physical story. I want my commits to tell the story that Feature X was built from three sequentially self-supporting changes XA, XB, and XC, not that, while developing Feature X, (1) I was sick for two days, (2) Bob committed an important unrelated hotfix to the mainline tree that (3) I had to work around, and (4) Sally had to later revert Bob's commit. That I was sick, that Bob commited a hotfix, that I had to work around it, and that Sally rolled it back are all real. They happened. But none of those things are fundamental to the nature of Feature X and how I rendered that nature into code. I consider that stuff noise and make sure it's gone before my commits land in production. But that's me. Maybe you care about that stuff. If so, your Git workflow and mine are going to be very different. And that's okay.

badman_ting 13y ago
> The perennial problem with discussions of Git workflows is the underlying belief that there exists, if only we can find it, the One True Workflow. This belief is false. Nothing in the post explicitly says this, nor is it implied. You just took 7 grafs to say "the best tool for the job".
- tmoertel 13y ago
  Thanks for your comment. To clarify, my comment was about "discussions of Git workflows." For example, the very discussion occurring here on HN in the wake of the original post. In this discussion, you will find numerous comments predicated on the implicit belief that there is some global ordering on Git workflows and, therefore, that one workflow can be strictly better than others. Some examples from the top level: > I think http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ is simpler and more robust. [1] > Just use Gitflow peeps. It's simple, not mentally taxing, and having a feature branch for each feature (JIRA ticket, or whatever unit you're using) makes things very atomic and simple. [2] > How is this in any way better or simpler than Git Flow? [3] > Rebase is a bad habit to get into (because it means other people can't pull your branches), and a pain to fix when it conflicts. Merge master into your working branch instead. [4] Also, I didn't write 7 grafs to say "the best tool for the job." I wrote 7 grafs to say that there is no "the job." Rather, there are many different jobs. Your job might be to record the physical story. Mine might be to record the logical story. Different jobs. Links: [1] https://news.ycombinator.com/item?id=7037265 https://news.ycombinator.com/item?id=7037265 [2] https://news.ycombinator.com/item?id=7037362 https://news.ycombinator.com/item?id=7037362 [3] https://news.ycombinator.com/item?id=7036934 https://news.ycombinator.com/item?id=7036934 [4] https://news.ycombinator.com/item?id=7037057 https://news.ycombinator.com/item?id=7037057
ricardobeat 13y ago
Not sure you were contesting the presented workflow in (1) (2) (3), but that won't happen when continuous rebasing on a branch. Bob and Sally's commits will remain on master and not be part of your branch at all; at merge time your feature will look like it was branched off the most recent master and contain only relevant commits.
- tmoertel 13y ago
  I wasn't contesting the original article's workflow (which is rather like the one I use most often), but picking one of the hotly contested battlegrounds of the Git Workflow Wars – To Rebase or Not To Rebase – and using it as an example.
mbesto 13y ago
> It depends on your preferences, which ought to reflect your team, your project, and your company culture. Like all tools (especially software ones), it's not how hard you swing the hammer, but rather that the nail ultimately gets secured. The two are often misinterpreted against each other.
kcorbitt 13y ago
Sure, but there are still workflows that are just plain bad[1], and articles like this one are an effective way of giving users better alternatives. [1] Last summer I interned for a company that had recently switched to git. The workflow was: you are assigned a feature and begin developing it on the shared "development" branch. As you make commits you note the hashes on the company issue tracker. When the feature is finished and signed off, the DevOps people manually parse through all the comments on the issue, manually cherry-pick (!) every commit (that you remembered to write down) to the "production" branch, push, and hope they didn't miss any.
- tmoertel 13y ago
  The point I'm hoping to make is that there is no universal < operator on workflows that lets us rank them in a way that makes sense for most teams. Different teams necessarily have their own, widely varying < operators, and applying these operators to the set of plausible workflows causes wildly varying workflows to rise to the top. There are, however, workflows that are so bad that they rank poorly under your < operator, my < operator, and just about every other reasonable person's < operator. Your example makes this painfully clear. Still, someone at the company you interned at had an < operator that pushed that horrible workflow to the top of the list. You can argue that that person was crazy, and maybe you would be right, but maybe that person wasn't. Maybe that person's < operator accounted for things you couldn't see. Maybe the company needed the Git workflow to contort itself into integrating with legacy processes that would have been hugely expensive to change. Whatever the reason, that person's < operator is not one that you or I would want to have forced upon us. Why then should we assume our personal < operators good enough to force upon anybody else, let alone everybody else?
rushi_agrawal 13y ago
For me, more the number of splits a commit can be divided into, the better. Even for simple 2-line cleanup, I'd not do it with the current patch I'm doing. This irks my fellow programmers sometimes though, who just want to get the work done.
- bazfoo 13y ago
  I've developed this habit as a consequence of using history to understand the context of a piece of code. Big commits make life harder for future maintainers.
randallsquared 13y ago
Here's why I care about that stuff: I work at a place that has some code in production that's over ten years old, and which no one now working there wrote. We have many more discrete systems than developers. The repo history, including its comments (actually currently in SVN, where rebasing isn't a ready option), is a major tool for interpreting the intent of authors now gone (or who now don't remember writing it, something I'm guilty of, certainly). The clean narrative you are asking for is there, in tickets and internal wiki pages. The actual history of commits helps tell a different story, about whether it was intentional that line 493 was omitted because of the effect on another part of the code, or whether it being missing is a merge artifact or other tool screwup. We're about to switch to git, and one of the things I worry about is that newer developers steeped in the ways of rebasing will come on board and "clean up" their commits to hide informative early missteps and paper over the cracks and seams of their work with single commit messages per feature which afford no understanding of the difficulties involved in developing it.

badman_ting 13y ago

> The perennial problem with discussions of Git workflows is the underlying belief that there exists, if only we can find it, the One True Workflow. This belief is false. Nothing in the post explicitly says this, nor is it implied. You just took 7 grafs to say "the best tool for the job".

tmoertel 13y ago
Thanks for your comment. To clarify, my comment was about "discussions of Git workflows." For example, the very discussion occurring here on HN in the wake of the original post. In this discussion, you will find numerous comments predicated on the implicit belief that there is some global ordering on Git workflows and, therefore, that one workflow can be strictly better than others. Some examples from the top level: > I think http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/ is simpler and more robust. [1] > Just use Gitflow peeps. It's simple, not mentally taxing, and having a feature branch for each feature (JIRA ticket, or whatever unit you're using) makes things very atomic and simple. [2] > How is this in any way better or simpler than Git Flow? [3] > Rebase is a bad habit to get into (because it means other people can't pull your branches), and a pain to fix when it conflicts. Merge master into your working branch instead. [4] Also, I didn't write 7 grafs to say "the best tool for the job." I wrote 7 grafs to say that there is no "the job." Rather, there are many different jobs. Your job might be to record the physical story. Mine might be to record the logical story. Different jobs. Links: [1] https://news.ycombinator.com/item?id=7037265 https://news.ycombinator.com/item?id=7037265 [2] https://news.ycombinator.com/item?id=7037362 https://news.ycombinator.com/item?id=7037362 [3] https://news.ycombinator.com/item?id=7036934 https://news.ycombinator.com/item?id=7036934 [4] https://news.ycombinator.com/item?id=7037057 https://news.ycombinator.com/item?id=7037057

ricardobeat 13y ago

Not sure you were contesting the presented workflow in (1) (2) (3), but that won't happen when continuous rebasing on a branch. Bob and Sally's commits will remain on master and not be part of your branch at all; at merge time your feature will look like it was branched off the most recent master and contain only relevant commits.

tmoertel 13y ago
I wasn't contesting the original article's workflow (which is rather like the one I use most often), but picking one of the hotly contested battlegrounds of the Git Workflow Wars – To Rebase or Not To Rebase – and using it as an example.

mbesto 13y ago

> It depends on your preferences, which ought to reflect your team, your project, and your company culture. Like all tools (especially software ones), it's not how hard you swing the hammer, but rather that the nail ultimately gets secured. The two are often misinterpreted against each other.

kcorbitt 13y ago

Sure, but there are still workflows that are just plain bad[1], and articles like this one are an effective way of giving users better alternatives. [1] Last summer I interned for a company that had recently switched to git. The workflow was: you are assigned a feature and begin developing it on the shared "development" branch. As you make commits you note the hashes on the company issue tracker. When the feature is finished and signed off, the DevOps people manually parse through all the comments on the issue, manually cherry-pick (!) every commit (that you remembered to write down) to the "production" branch, push, and hope they didn't miss any.

tmoertel 13y ago
The point I'm hoping to make is that there is no universal < operator on workflows that lets us rank them in a way that makes sense for most teams. Different teams necessarily have their own, widely varying < operators, and applying these operators to the set of plausible workflows causes wildly varying workflows to rise to the top. There are, however, workflows that are so bad that they rank poorly under your < operator, my < operator, and just about every other reasonable person's < operator. Your example makes this painfully clear. Still, someone at the company you interned at had an < operator that pushed that horrible workflow to the top of the list. You can argue that that person was crazy, and maybe you would be right, but maybe that person wasn't. Maybe that person's < operator accounted for things you couldn't see. Maybe the company needed the Git workflow to contort itself into integrating with legacy processes that would have been hugely expensive to change. Whatever the reason, that person's < operator is not one that you or I would want to have forced upon us. Why then should we assume our personal < operators good enough to force upon anybody else, let alone everybody else?

rushi_agrawal 13y ago

For me, more the number of splits a commit can be divided into, the better. Even for simple 2-line cleanup, I'd not do it with the current patch I'm doing. This irks my fellow programmers sometimes though, who just want to get the work done.

bazfoo 13y ago
I've developed this habit as a consequence of using history to understand the context of a piece of code. Big commits make life harder for future maintainers.

randallsquared 13y ago

Here's why I care about that stuff: I work at a place that has some code in production that's over ten years old, and which no one now working there wrote. We have many more discrete systems than developers. The repo history, including its comments (actually currently in SVN, where rebasing isn't a ready option), is a major tool for interpreting the intent of authors now gone (or who now don't remember writing it, something I'm guilty of, certainly). The clean narrative you are asking for is there, in tickets and internal wiki pages. The actual history of commits helps tell a different story, about whether it was intentional that line 493 was omitted because of the effect on another part of the code, or whether it being missing is a merge artifact or other tool screwup. We're about to switch to git, and one of the things I worry about is that newer developers steeped in the ways of rebasing will come on board and "clean up" their commits to hide informative early missteps and paper over the cracks and seams of their work with single commit messages per feature which afford no understanding of the difficulties involved in developing it.