Hacker News new | past | comments | ask | show | jobs | submit login

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.



Then you don't actually need merge? Am I missing something?

If you always rebase the branch, the commits can be applied directly.


You're missing the merge commits. `git log` is a key feature and merges belong there, at least in my workflow.


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.


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.


Totally on board (except the forbidden -a switch).

The last command is:

    cp .git/refs/heads/feature .git/refs/heads/main
No merge needed.


Touching files in .git (outside of like, .git/config) directly gives me the heebee jeebees


Fair point, and I would not advocate that specific workflow! My point was just to illustrate that we can live without merge.


    git reset --hard main feature




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: