7 ms·

Big fan of Git style guides in teams. We had one at Thread. It was common for engineers to come in and find we didn't do rebasing and find it weird, but we took

Big fan of Git style guides in teams. We had one at Thread. It was common for engineers to come in and find we didn't do rebasing and find it weird, but we took the opinion that history should be exactly what you actually did, not some clean and idealised version of what you wish you had done. There are advantages and disadvantages to this, but having a defined approach was the most important aspect. Also the fact that we didn't rebase and used merges everywhere was a major contributor to no one ever breaking their git repos, something that git seems notorious for elsewhere.

throwawaylinux 4y ago
> that history should be exactly what you actually did That gives you the history of exactly what git commits you made, not exactly what you did and how you went about solving the problem though, right? git describes changes to the source. It seems like you're getting the worst of both worlds, trying to understand how the source changed is much harder when you have peoples' experiments and draft changes and false starts littering the history. And understanding the approach to problem solving and why decisions were made is pretty unsatisfying by digging through that stuff too really. That seems better kept as documentation and/or in the commit logs.
Shorel 4y ago
For me, there should be a balance between the detail of history and the usefulness of the information. For the changes I do, not only I rebase them all in a single commit, I don't even merge branches. I cherry-pick my changeset. Clean commits, clean history. Whatever I do before a push is my business and no one's else. For anyone else changes, that's it, anyone who is not me: history is untouchable. No rebases, no squash, whatever it is already pushed, must stay as it is. When I do a pull: git stash, git pull --rebase, git stash pop I encourage everyone to clean their commits before a push. A clean history is a good history.
tyingq 4y ago
What about squashing commits in a merge? I don't do that all the time, but it is useful for certain things. Like repeated code changes to test something in the CI/CD pipeline (that I can't replicate well locally), where only the last change that got it working is of any interest.
- prettyStandard 4y ago
  Squashing is rewriting history. It sounds like the grandcomment had a ban against rewriting history across-the-board, which would help make git idiot proof. I love rewriting history, not because it's what I wished I had done but because it's what I am going to want to review when I have to. Rewriting history is a great way for gitiots to shoot themselves in the foot.
  - peteradio 4y ago
    Couldn't you rewrite history locally on your own branch and nobody would know?
    - prettyStandard 4y ago
      Yeah... You should never rewrite history of shared branches. You are just asking for trouble in that case.
    - danpalmer 4y ago
      We informally allowed whatever you wanted until you opened a pull request.
    - chrisfinazzo 4y ago
      Hard agree. Do whatever the heck you want locally, just try not to screw everybody else up when you push. (From the guy who force-pushed on a personal project yesterday to resolve a situation with multiple remote heads - I am ashamed)
    - opsy_ 4y ago
      Sure, unless you bork your local repo enough you need help from a teammate getting your work into a PR. Not to say that doesn't make for a good learning moment.
      - OkayPhysicist 4y ago
        At some point, every junior is going to mangle something, and need a senior to sit them down and give them the git reflog talk. It's an inevitability, and should be embraced as a natural part of the evolution of a developer.
idop 4y ago
Obviously what works for you works for you, but I respectfully disagree with everything you said. The "history should be exactly what you did" argument - which many people make - is really funny to me because a pull/merge-only strategy only preserves the _wrong_ history. As a tech lead, for example, I absolutely do not care one bit about the date of a commit, or when the developer started working on it, or what was the commit they started working on top of. That may be "what really happened", but it's worth nothing in the grand scheme of things. When a commit _has made it into the product_ is the only " what really happened" there is, and that is what I care about. And a linear history makes this much easier to analyze and understand, reducing cognitive load considerably. Also, it's strange that you see merges as a contributor to keeping repos from breaking, as my experience is the opposite. I advocate for a rebase-based strategy wherever I go as it helps developers push better code, it actually curbs hysteria-driven "merge it as fast as possible no matter how shit it is" cases, and I see how it turns the Git log into an actually useful source of information for developers and other personas. People start reading the logs! The log should track the product's evolution, not the developers' activities.
- mibollma 4y ago
  I disagree with both of you :). Personally I prefer to squash to one commit per ticket but on a team level I don't care about a consistent way. I've found that the history rarely doesn't matter at all to me. Finding out who modified a specific code section (git blame) is usually good enough.
  - CBarkleyU 4y ago
    In the hopes someone will see this: Why isnt this the standard? I've never been in the position of coordinating multiple engineers, but when I look at my colleagues code I never ever once cared about their individual commits. What am I missing?
- rtepopbe 4y ago
  My current thought on this is that the git model (or at least the interface for it) is probably a touch too simple to accommodate all the things people want to use it for. As a result, you get this whole 'clean history' vs 'what really happened' split. And often you can find a few more splits if you dig in a bit deeper into the actual mechanics people prefer. Generally, bigger picture stuff works best with cleaner histories as they mop up a bunch of unnecessary and distracting details, and neatly package things together. But doing so also means you're getting rid of, well, the details. If you need them later - and some poor bastard always will - you're just screwed. Unfortunately all we've got are commits, so you're constantly fighting different groups and even different people who value the benefits of different approaches due to their positions, histories, or preferences. This isn't even a half-baked idea at this point, but at first glance something like a meta-commit which just contains more commits and a message seems like it might be better. The top-level commits could just be the 'clean history' while deeper levels could record more of the as-happened details.
hinkley 4y ago
Telling people not to rebase and having code that was never rebased are two very different things. Have you asked former employees if they rebased when nobody was looking? If you haven’t then you have no reliable data on what happens. When people set ridiculous absolute rules, what develops is an underground of people who don’t follow the rules and in some cases get a thrill from subverting the dystopia.
- eikenberry 4y ago
  When I hear 'no-rebasing' I hear 'no-rebasing after you've done a PR'. That's when my code and commits are ready for others. My ongoing commits are often more notes to myself as I find those more useful during the work but make no sense as pushed commit messages where you need to block things off logically. Organizing your commits is not much different than organizing your code into modules. Something that should be done purposefully and with forethought.
- danpalmer 4y ago
  To clarify, this wasn't an enforced hard-rule, but instead just a written down style guide. Style guides can always be broken for good reason, but it's the sort of thing that a code reviewer might comment on or discourage. Generally rebasing before opening a PR was considered to be fine.
eternalban 4y ago
> history should be exactly what you actually did, not some clean and idealised version of what you wish you had done. This is a false premise. There is a product (and its various versions), and the team that develops it. Both have a claim to a meaningful definition of "history". What you are arguing is that the 'history of developer' is more fundamental than a less noisy 'history of the product development'. Does it really matter (and need we record it for posterity) if developer x used n commits to post n incremental changes to a well defined software unit of the product? It seems a comprise position of (1) no history rewrites before code review, followed by (2) post code review cleansing squash before merge would satisfy all concerns and history records have also served their purpose. . A developer's timeline is relevant to her team lead, not the product manager.
cnity 4y ago
If the employer I worked for started micro-managing the way I use my tools (that affects nobody else) I would consider leaving, honestly. If I rebase on a branch that hadn't been shared with someone else, why does it matter what my boss or team thinks about that approach? Code styles are one thing, what I type into my terminal is another.
- gardenhedge 4y ago
  When you commit you're sharing with your team and future team. I think it's fair to have a set of agreed guidelines around that. What if you wanted to put all your commit messages as "cnity did it"?
  - bacon_waffle 4y ago
    I agree with the post you're responding to, and make a lot more commits than I share with my team. Pushing commits to a shared branch is where work is shared. At my current employer, we used to use Perforce, and in that world you're totally right that committing (submitting in Perforce terminology, IIRC) did share changes. In that context, we developed a lot of bad patterns, losing code or holding up other people's work while a developer got their work ready to share. Transitioning to git has been super painful, due mainly to people treating git as if it's the same sort of thing as Perforce...
  - cnity 4y ago
    It's simple: I wouldn't do that. Do we need guidelines to not delete repositories too?
    - gardenhedge 4y ago
      Yes of course
ajkjk 4y ago
gosh, wow, I want the opposite of that for any project I work on. In the last five years I have never used a merge commit and I love it. I'd honestly prefer a version of git that doesn't have em.
- umvi 4y ago
  Without merge commits you can never have more than 1 long-lived branch because said long-lived branches will not have any common ancestors which makes pulling changes between them a nightmare (literally every file will be in conflict)... I like linear histories too, but if you have a production branch and a development branch you need merge commits between them.
  - amrocha 4y ago
    long lived branches are an anti pattern so this sounds like a plus to me
    - deleted 4y ago
      [deleted]
    - erik_seaberg 4y ago
      I’d rather wait until a project is finished, than to push incomplete changes that (I hope) aren’t reachable. But a long-lived branch needs to be rebased before review, because conflict resolutions need to be reviewed. In fact reviewing the version without the conflict resolutions is a waste of time, because that version probably won’t ever be deployed.
  - chociej 4y ago
    I don't think either of those is necessarily true. I don't ever need to merge long lived branches if I don't want to. And I definitely don't ever merge my production branches with... anything. They are always just a fast-forward from another branch.
    - umvi 4y ago
wizofaus 4y ago
Technically your git history isn't a record of what you did, only what you committed. If I make a bunch of changes locally, commit then realise I need to make a few extra changes before pushing there's really no harm amending the commit. But once pushed, I agree, it should stay as is.

throwawaylinux 4y ago

> that history should be exactly what you actually did That gives you the history of exactly what git commits you made, not exactly what you did and how you went about solving the problem though, right? git describes changes to the source. It seems like you're getting the worst of both worlds, trying to understand how the source changed is much harder when you have peoples' experiments and draft changes and false starts littering the history. And understanding the approach to problem solving and why decisions were made is pretty unsatisfying by digging through that stuff too really. That seems better kept as documentation and/or in the commit logs.

Shorel 4y ago

For me, there should be a balance between the detail of history and the usefulness of the information. For the changes I do, not only I rebase them all in a single commit, I don't even merge branches. I cherry-pick my changeset. Clean commits, clean history. Whatever I do before a push is my business and no one's else. For anyone else changes, that's it, anyone who is not me: history is untouchable. No rebases, no squash, whatever it is already pushed, must stay as it is. When I do a pull: git stash, git pull --rebase, git stash pop I encourage everyone to clean their commits before a push. A clean history is a good history.

tyingq 4y ago

What about squashing commits in a merge? I don't do that all the time, but it is useful for certain things. Like repeated code changes to test something in the CI/CD pipeline (that I can't replicate well locally), where only the last change that got it working is of any interest.

prettyStandard 4y ago
Squashing is rewriting history. It sounds like the grandcomment had a ban against rewriting history across-the-board, which would help make git idiot proof. I love rewriting history, not because it's what I wished I had done but because it's what I am going to want to review when I have to. Rewriting history is a great way for gitiots to shoot themselves in the foot.
- peteradio 4y ago
  Couldn't you rewrite history locally on your own branch and nobody would know?
  - prettyStandard 4y ago
    Yeah... You should never rewrite history of shared branches. You are just asking for trouble in that case.
  - danpalmer 4y ago
    We informally allowed whatever you wanted until you opened a pull request.
  - chrisfinazzo 4y ago
    Hard agree. Do whatever the heck you want locally, just try not to screw everybody else up when you push. (From the guy who force-pushed on a personal project yesterday to resolve a situation with multiple remote heads - I am ashamed)
  - opsy_ 4y ago
    Sure, unless you bork your local repo enough you need help from a teammate getting your work into a PR. Not to say that doesn't make for a good learning moment.
    - OkayPhysicist 4y ago
      At some point, every junior is going to mangle something, and need a senior to sit them down and give them the git reflog talk. It's an inevitability, and should be embraced as a natural part of the evolution of a developer.

idop 4y ago

Obviously what works for you works for you, but I respectfully disagree with everything you said. The "history should be exactly what you did" argument - which many people make - is really funny to me because a pull/merge-only strategy only preserves the _wrong_ history. As a tech lead, for example, I absolutely do not care one bit about the date of a commit, or when the developer started working on it, or what was the commit they started working on top of. That may be "what really happened", but it's worth nothing in the grand scheme of things. When a commit _has made it into the product_ is the only " what really happened" there is, and that is what I care about. And a linear history makes this much easier to analyze and understand, reducing cognitive load considerably. Also, it's strange that you see merges as a contributor to keeping repos from breaking, as my experience is the opposite. I advocate for a rebase-based strategy wherever I go as it helps developers push better code, it actually curbs hysteria-driven "merge it as fast as possible no matter how shit it is" cases, and I see how it turns the Git log into an actually useful source of information for developers and other personas. People start reading the logs! The log should track the product's evolution, not the developers' activities.

mibollma 4y ago
I disagree with both of you :). Personally I prefer to squash to one commit per ticket but on a team level I don't care about a consistent way. I've found that the history rarely doesn't matter at all to me. Finding out who modified a specific code section (git blame) is usually good enough.
- CBarkleyU 4y ago
  In the hopes someone will see this: Why isnt this the standard? I've never been in the position of coordinating multiple engineers, but when I look at my colleagues code I never ever once cared about their individual commits. What am I missing?
rtepopbe 4y ago
My current thought on this is that the git model (or at least the interface for it) is probably a touch too simple to accommodate all the things people want to use it for. As a result, you get this whole 'clean history' vs 'what really happened' split. And often you can find a few more splits if you dig in a bit deeper into the actual mechanics people prefer. Generally, bigger picture stuff works best with cleaner histories as they mop up a bunch of unnecessary and distracting details, and neatly package things together. But doing so also means you're getting rid of, well, the details. If you need them later - and some poor bastard always will - you're just screwed. Unfortunately all we've got are commits, so you're constantly fighting different groups and even different people who value the benefits of different approaches due to their positions, histories, or preferences. This isn't even a half-baked idea at this point, but at first glance something like a meta-commit which just contains more commits and a message seems like it might be better. The top-level commits could just be the 'clean history' while deeper levels could record more of the as-happened details.

hinkley 4y ago

Telling people not to rebase and having code that was never rebased are two very different things. Have you asked former employees if they rebased when nobody was looking? If you haven’t then you have no reliable data on what happens. When people set ridiculous absolute rules, what develops is an underground of people who don’t follow the rules and in some cases get a thrill from subverting the dystopia.

eikenberry 4y ago
When I hear 'no-rebasing' I hear 'no-rebasing after you've done a PR'. That's when my code and commits are ready for others. My ongoing commits are often more notes to myself as I find those more useful during the work but make no sense as pushed commit messages where you need to block things off logically. Organizing your commits is not much different than organizing your code into modules. Something that should be done purposefully and with forethought.
danpalmer 4y ago
To clarify, this wasn't an enforced hard-rule, but instead just a written down style guide. Style guides can always be broken for good reason, but it's the sort of thing that a code reviewer might comment on or discourage. Generally rebasing before opening a PR was considered to be fine.

eternalban 4y ago

> history should be exactly what you actually did, not some clean and idealised version of what you wish you had done. This is a false premise. There is a product (and its various versions), and the team that develops it. Both have a claim to a meaningful definition of "history". What you are arguing is that the 'history of developer' is more fundamental than a less noisy 'history of the product development'. Does it really matter (and need we record it for posterity) if developer x used n commits to post n incremental changes to a well defined software unit of the product? It seems a comprise position of (1) no history rewrites before code review, followed by (2) post code review cleansing squash before merge would satisfy all concerns and history records have also served their purpose. . A developer's timeline is relevant to her team lead, not the product manager.

cnity 4y ago

If the employer I worked for started micro-managing the way I use my tools (that affects nobody else) I would consider leaving, honestly. If I rebase on a branch that hadn't been shared with someone else, why does it matter what my boss or team thinks about that approach? Code styles are one thing, what I type into my terminal is another.

gardenhedge 4y ago
When you commit you're sharing with your team and future team. I think it's fair to have a set of agreed guidelines around that. What if you wanted to put all your commit messages as "cnity did it"?
- bacon_waffle 4y ago
  I agree with the post you're responding to, and make a lot more commits than I share with my team. Pushing commits to a shared branch is where work is shared. At my current employer, we used to use Perforce, and in that world you're totally right that committing (submitting in Perforce terminology, IIRC) did share changes. In that context, we developed a lot of bad patterns, losing code or holding up other people's work while a developer got their work ready to share. Transitioning to git has been super painful, due mainly to people treating git as if it's the same sort of thing as Perforce...
- cnity 4y ago
  It's simple: I wouldn't do that. Do we need guidelines to not delete repositories too?
  - gardenhedge 4y ago
    Yes of course

ajkjk 4y ago

gosh, wow, I want the opposite of that for any project I work on. In the last five years I have never used a merge commit and I love it. I'd honestly prefer a version of git that doesn't have em.

umvi 4y ago
Without merge commits you can never have more than 1 long-lived branch because said long-lived branches will not have any common ancestors which makes pulling changes between them a nightmare (literally every file will be in conflict)... I like linear histories too, but if you have a production branch and a development branch you need merge commits between them.
- amrocha 4y ago
  long lived branches are an anti pattern so this sounds like a plus to me
  - deleted 4y ago
    [deleted]
  - erik_seaberg 4y ago
    I’d rather wait until a project is finished, than to push incomplete changes that (I hope) aren’t reachable. But a long-lived branch needs to be rebased before review, because conflict resolutions need to be reviewed. In fact reviewing the version without the conflict resolutions is a waste of time, because that version probably won’t ever be deployed.
- chociej 4y ago
  I don't think either of those is necessarily true. I don't ever need to merge long lived branches if I don't want to. And I definitely don't ever merge my production branches with... anything. They are always just a fast-forward from another branch.
  - umvi 4y ago

wizofaus 4y ago

Technically your git history isn't a record of what you did, only what you committed. If I make a bunch of changes locally, commit then realise I need to make a few extra changes before pushing there's really no harm amending the commit. But once pushed, I agree, it should stay as is.