4 ms·

Rebase is only dangerous and problematic if your team shares ownership of feature branches. I have yet to work at a place where that is the case. I have, howev

Rebase is only dangerous and problematic if your team shares ownership of feature branches. I have yet to work at a place where that is the case. I have, however, seen many git trees that are a complete mess to grok because of merges into feature branches.

disgruntledphd2 6y ago
Yeah, 23 commits into master from one feature branch is not normally a great idea. When I worked at a large FAANG they enforced only one commit from a feature branch into master. I didn't realise why that was a good idea until I saw the alternatives ;)
- matt-attack 6y ago
  Can you explain “commits into master”? I thought you make a feature branch, do countless commits to it, then either merge or rebase into master. Where does the number of commits into master come Into play?
  - minot 6y ago
    I’m guilty of doing things wrong. Let’s say the cto has said no merge to master until after n days. I have a few defects that I need to work on that are in the same files. Ideally, one should make a different branch for each defect. However, I’ll have to deal with merge conflicts when I merge to master next week. So, I put multiple defects in the same branch and put tracking information in commit message for example Use break word in result table Since we allow first names to be up to a hundred characters in length, the table should stay within the constraints in its container even with a hundred no space characters For #4007 — As you can imagine this isn’t ideal on multiple levels. First, a merge request should only address one concern. That being said, the problem pretty much lies somewhere else. The second follows the first. Assuming the first, we should be able to squash all commits in the feature branch without losing information. I’m sure this is a common problem but I’ve not heard of a good solution to it so far. I’d love to hear what I should do differently.
    - disgruntledphd2 6y ago
      > Let’s say the cto has said no merge to master until after n days. This seems like the problem you should address first.
      - minot 6y ago
        Failed to meet deadline for release (not enough confidence that we can release without regressions) so release got pushed to next release window which is n - 1 days from now. I imagine ideally we should use tags for release but for some reason we don't do that.
  - disgruntledphd2 6y ago
    So it's the notion that commits should be squashed before merging into master, rather than merging all N commits from the branch into master.
matt-attack 6y ago
How should more than one person collaborate on a new feature?
- jamil7 6y ago
  Ideally the feature can be split into more granular components that individuals can work on.

disgruntledphd2 6y ago

Yeah, 23 commits into master from one feature branch is not normally a great idea. When I worked at a large FAANG they enforced only one commit from a feature branch into master. I didn't realise why that was a good idea until I saw the alternatives ;)

matt-attack 6y ago
Can you explain “commits into master”? I thought you make a feature branch, do countless commits to it, then either merge or rebase into master. Where does the number of commits into master come Into play?
- minot 6y ago
  I’m guilty of doing things wrong. Let’s say the cto has said no merge to master until after n days. I have a few defects that I need to work on that are in the same files. Ideally, one should make a different branch for each defect. However, I’ll have to deal with merge conflicts when I merge to master next week. So, I put multiple defects in the same branch and put tracking information in commit message for example Use break word in result table Since we allow first names to be up to a hundred characters in length, the table should stay within the constraints in its container even with a hundred no space characters For #4007 — As you can imagine this isn’t ideal on multiple levels. First, a merge request should only address one concern. That being said, the problem pretty much lies somewhere else. The second follows the first. Assuming the first, we should be able to squash all commits in the feature branch without losing information. I’m sure this is a common problem but I’ve not heard of a good solution to it so far. I’d love to hear what I should do differently.
  - disgruntledphd2 6y ago
    > Let’s say the cto has said no merge to master until after n days. This seems like the problem you should address first.
    - minot 6y ago
      Failed to meet deadline for release (not enough confidence that we can release without regressions) so release got pushed to next release window which is n - 1 days from now. I imagine ideally we should use tags for release but for some reason we don't do that.
- disgruntledphd2 6y ago
  So it's the notion that commits should be squashed before merging into master, rather than merging all N commits from the branch into master.

matt-attack 6y ago

How should more than one person collaborate on a new feature?

jamil7 6y ago
Ideally the feature can be split into more granular components that individuals can work on.