The Git Slinger
You're the fastest committer this side of the stack. You are speed. You put forth Pull Requests with no less than 25 commits and it only took you a day. Who needs rules about formatting when you commit like it's a Yahoo chatroom in the 90s.
The Silo
MY PRECIOUS! You hoard your commits and only those that are worthy get pushed. No one sees your true commits, only the ones you absolutely have to let loose into the wild. Your local repo is filled with commits and branches that will never see the light of another repo.
The Re-Re-Rebaser
You like to play fast and loose with git commits. Who cares if they get rewritten. Merges are for losers and that's not you. You rebase everything, even your thoughts. Why merge when you can just replay 30 commits on top of master. Conflicts be damned.
The Ancient One
Your commits are based off of a release that no one has seen for months. You've been working off of the same branch and when you go to submit a pull request, you're shocked to learn you have so many merge conflicts. The team groans at sorting out the mess you've made.
The Go-With-The-Git-Flow
Ok, so bugfix branches are branched off of and merge into release branches. Feature branches get merged to develop. Releases di-merge into develop and master. Hotfix branches only branch off of master. The answer: MORE BRANCHES.
The Singularity
docs: git commits should be read by machines, not humans [skip-ci]
feat(dev.to): add emoji to commits to prove sentience :heart:
Slides into the CI/CD server's DMs
hey girl, heyyyyy!
Well, Actually...
Well, actually, git commits are like emails with a subject line and a body, but the subject line is most important.
Well, actually, git commits should be no more than 50 characters, any more than that is just wasteful
Well, actually, rebasing is better than merging...
Well, actually, the best git workflow is...
Choose your own!
Add your own personality in the comments!
Top comments (5)
I've been all of these!
Done most but not rebase, seen that cause nothing but problems as it tends to get used incorrectly by people not familiar with it
This feeling I recognize. But I think my colleagues are smarter than me, so they should be able to master the tools. I advise our team to rebase.
Those tiny fixups, the style changes, the reverts... They matter to your coding coach, or serve as a short term backup, but should not at all end up in the code history.
I must say that those who can truly limit their changes to what is required (and not add unrelated changes) barely ever need to ask for help rebasing. The others complain about conflicts.
Rebase-chains take some time to master. But the resulting history leaves no doubt about what is in a merge request, in a release, a patch, ...
The yedi.
Force pushing your commits. Those are the commits you are looking for!
I guess I'm mostly "The Go-With-The-Git-Flow"