Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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




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

Search: