64 ms·

Proper use of merge is table stakes. You get warned in your PR if your non-main branch is out of date with your main branch, and after you rebase and force push

Proper use of merge is table stakes. You get warned in your PR if your non-main branch is out of date with your main branch, and after you rebase and force push your non-main branch, you review the diff in the PR.

couchand 4y ago
Then you don't actually need merge? Am I missing something? If you always rebase the branch, the commits can be applied directly.
- xxpor 4y ago
  if you do this: (starting on main) git checkout -b feature do work git commit -a git checkout main git pull git checkout feature git rebase main publish code review, get approval git checkout main git merge feature You still use merge at the end, even though it's not actually doing anything that'll result in a conflict.
  - couchand 4y ago
    Totally on board (except the forbidden -a switch). The last command is: cp .git/refs/heads/feature .git/refs/heads/main No merge needed.
    - xxpor 4y ago
      Touching files in .git (outside of like, .git/config) directly gives me the heebee jeebees
      - couchand 4y ago
        Fair point, and I would not advocate that specific workflow! My point was just to illustrate that we can live without merge.
    - a_t48 4y ago
      git reset --hard main feature
  - micw 4y ago
    Rather than switching to "main" and pull it, you can just stay in "feature" and do a fetch followed by "rebase origin/main". Then pull "main" before you merge the feature. I'd also use "merge --no-ff" to force an empty commit that visualizes where a feature begins and ends.
- benatkin 4y ago
  You're missing the merge commits. `git log` is a key feature and merges belong there, at least in my workflow.