Replying to Avatar jb55

Once I have people I can trust to collect patches into trees I can just merge large subtrees of changes like linus does it. Its very scalable. People just need to learn how to do proper git commits that are logically distinct and can be cherry picked incrementally and independently. Developers don’t have this skill anymore because github doesn’t force you to think about it.

Once people learn how to do this I would feel more comfortable letting maintainers collect many changes into their own forks that I merge all at once. I kind of do this already with #[2]​‘s translation PR but I still find myself formatting the branch and removing duplicate commits, etc.

It would save me a lot of time if contributors learned git and used it effectively so I don’t have to spend all day formatting patches, rebasing, squash merging, and fixing conflicts.
72
nobody 2y ago

This is something I'm working on myself at work. We have that one Git ninja, who makes sense of all our messes. The boss hates Git and refuses to learn it properly, while I'm just trying to not add grey hairs to our ninja.

Do you have any learning resources that you recommend? Not the basic "this is how you commit" type of stuff, but more the methodology of really working in a group with Git? This is where I have found most of the literature to be lacking. I learned more from a recent JetBrains blog then I did from the o'Reilly and Packt books I read on the topic.

Reply to this note

Please Login to reply.

Discussion

Avatar
jb55 2y ago

The git book is the gold standard. Git finally clicked for me when i read about its internals:

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

72
nobody 2y ago

Thank you much.

Avatar
minh 2y ago

🤙