Re:Extremely Linear Git History
by benatkin on Tuesday November 22, 2022 @12:42PM
(#33708517)
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.
[ Parent
| on HN ]
Then you don't actually need merge? Am I missing something?
If you always rebase the branch, the commits can be applied directly.
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.
Totally on board (except the forbidden -a switch).
The last command is:
cp .git/refs/heads/feature .git/refs/heads/main
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 featureRather 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.