You must log in or register to comment.
We’re currently training some devs from another team, which were doing some development before, but it wasn’t their bread-and-butter.
And yeah, commit messages are one of the bigger differences, where they just don’t quite take things as seriously.
But that’s due to a chicken-egg problem. They’re not really well-versed in creating atomic commits, and apparently so far, they’ve been merging basically at random, creating a rather complex history.
And of course, they’ve been embedded in a team where everyone else didn’t take these things as serious. So, even if they put lots of efforts into their commits, they’re be much less useful when they’re placed between badly separated commits.Really makes me feel like we need to put special focus on Git for a while, to give them the tools to appreciate working in our useful commit history.
Fun fact: attempting to use an “old style” bitmap block-graphics font will make you notice one or two characters that are no longer usable in modern text display systems (e.g. word processors or browsers);
- non breaking space
- soft hyphen
I have a non-breaking space on my layout since 10 years, and a friend recently added a non-breaking hyphen to his. Appart from search that doesn’t do automatic conversion I didn’t noticed issues.
iirc, the issue wasn’t so much SHY being used for its intended purpose, as byte 0xAD no longer being available for use as a normal character.
Imagine getting a game map file from the 80s in which lots of (more than 224) characters were used as block graphics, and you have a matching font. You open the “text” file with the appropriate font, and notice gaps in what should be a grid because all of the 0xAD are missing.
Effectively ISO-8859 and similar have become so common that it’s really hard to convince any modern system to treat “text” bytes as not following some standard in which the 0xAD becomes non-printable.
Meh. I’d argue that info should be in a merge request, than in a commit comment.
Not certain how this organization does it, but a branch contain all the backstory and context. Commits are labels inside a branch, of which there can be many.
Well, there’s different workflows. Big organizations tend to meticulously craft these branches and then do a big bang merge at the end.
But for smaller organizations/teams, it’s usually more useful to merge as early as possible, i.e. work directly on a single branch together. This avoids complex merge conflicts and allows others to benefit from your work as early as possible.
In particular, smaller teams tend to also go together with smaller projects, where many features may be completed in a single commit, so there’s not much of a backstory to tell…The proper way to organize a branch is as a logical sequence of sub-features - each represented by a commit. Ideally, the commits should not break the build while introducing its feature. In many such cases, each commit may have a back story - the tests you did, your decision process, online references (that apply only to that commit - something like stackoverflow answers), etc.
Branch messages don’t have the fidelity to capture such information. You may question the need for such detailed info. However, along with git blame and bisect, those commit messages are invaluable. I have lost count of how many times my own detailed commit messages helped me. And while I don’t usually look at others’ commits in such detail, I do read the details of commits that I’m interested in.
Git (and other VCSs) isn’t just a snapshot tool. It’s a history tool with the ability to capture history documentation. Honestly, Git is extremely underutilized in that capacity.
