Git

2541 readers

10 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

[email protected]

My favourite Git commit (dhwthompson.com)

submitted 9 months ago by [email protected] to c/[email protected]

7 comments fedilink hide all child comments

top 7 comments

sorted by: hot top controversial new old

[–] [email protected] 4 points 9 months ago

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.

[–] [email protected] 1 points 9 months ago* (last edited 9 months ago) (1 children)

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

[–] [email protected] 1 points 9 months ago (1 children)

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.

[–] [email protected] 1 points 9 months ago* (last edited 9 months ago)

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.

[–] [email protected] 0 points 9 months ago (2 children)

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.

[–] [email protected] 4 points 9 months ago* (last edited 9 months ago)

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...

[–] [email protected] 2 points 9 months ago

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.