this post was submitted on 31 Jan 2024
220 points (98.7% liked)
Git
2909 readers
1 users here now
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Resources
Rules
- Follow programming.dev rules
- Be excellent to each other, no hostility towards users for any reason
- No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I was trying to learn this again last week. I just play around with this stuff for fun.
If I want to consolidate all the commits into a a single message (to create a changelog sort of), which kind of merge do I use?
Another question: I'm torn between wanting to keep a complete history of my work, for my own benefit, and not wanting anyone to see how messy and crappy everything is. I've been trying to work in one branch then merge only when a task is "complete". But it's a bit confusing for me especially if I leave a project for a while then come back to it. Especially especially if submodules are involved. Is there some sort of convention about how to do this? Or am I thinking about it wrong?
You want to have commit history, not a commit fairy tale. Once you start rewriting history, it's not really history any more. The stuff people want to hide tends to be some of the most useful to someone looking through the history to find out how things became the way they are and what was going through the author's mind when it was written. If things are messy and crappy, it's better to know that rather than have it covered up.
I'll remember that! Makes sense.