Commit often, perfect later, publish once: Git best practices (2013)

Re:Commit often, perfect later, publish once: Git best pract... by ChrisMarshallNY on Sunday July 04, 2021 @06:07AM (#27728518)

The old Perforce Mainline Model[0] prescribes regular merges from the mainline into your working branch, in order to reduce the hit, when you merge back down, into the mainline.

Basic common sense, and it also applies to git. With git, those regular up-merges are a lot easier.

Personally, I have been using git for years, and have never looked back at Perforce, but learning on more primitive VCSes taught me a disciplined, careful approach.

I did have to “unlearn” a few things (mostly, relaxing, and having more faith in the tool), but the transition has been fairly smooth.

[0] https://www.perforce.com/video-tutorials/vcs/mainline-model-...

[ Parent | on HN ]

Re:Commit often, perfect later, publish once: Git best pract... by marton78 on Sunday July 04, 2021 @08:57AM (#27729287)

I agree with this advice in spirit, but I prefer rebasing regularly onto master, rather than merging. Especially in a long lived branch this keeps the list of changes small. Imagine that someone performed a huge refactor in master, which conflicts with some small thing you did in your branch. If doesn't help to have another commit of the huge refactor in your history: the merge commit. I very much prefer to see only the logical changes I did in my branch.

[ Parent | on HN ]

Re:Commit often, perfect later, publish once: Git best pract... by ChrisMarshallNY on Sunday July 04, 2021 @09:16AM (#27729400)

That makes sense, as long as the work I do isn't that "huge refactor," for someone else.

[ Parent | on HN ]