This article hit one of my biggest pet peeves - conflating GitHub with git. No, rebase, commit, pull etc are _not_ “GitHub” commands.
It also seemed to dissuade users from taking their git history seriously. Acting like Git is super confusing helps nobody. Don’t get me wrong, it _is_ confusing at first, but taking on that mentality only holds you back. Case in point: the number of coworkers I have who are afraid to rebase their dev branch onto master. It’s no harder than a merge, yet some people are terrified of it.
—
The rest of the advice is fine, albeit a little cliche.
Rebases are frequently much harder than merges if there's any conflicts. Rebases means replaying your commits on a different base. If you have multiple commits to an area of the code which is different in the new base, you'll be resolving conflicts repeatedly. Depending on how much work and how many commits in your dev branch, it can easily get to be more effort than it's worth.
IMO a clean commit tree that looks pretty and doesn't have repeated merges of the updated base branch is severely overrated, particularly in a team environment. If you've ever pushed your dev branch and you rebase, you've probably made someone else's day miserable, maybe not today, but some day very soon.
If you have someone dedicated to nice git history, and lock down your git server with sufficient hooks to ensure whichever branch you want to have a beautiful history has one, perhaps it can be made to work. I don't really see the upside.
Source control is occasionally - not often, but occasionally - useful for going back in time. Mostly it's useful for avoiding conflict in the face of concurrent commits, and for finding out why a particular line of code was written (we put JIRA task ids in every commit message). But even with the time travelling, all you need is something you can traverse. How pretty it looks isn't very functional.
Git brought a whole new way of thinking about versioning to the masses. There are many concepts in git that were probably never encountered before in many people's careers. Combine that with the confusing git user interface and people are left feeling bewildered. Prior to git, you didn't have to spend a lot of time understanding your version control system. You learned a few commands and it just worked. Yes, many things were more work to accomplish, but they were simple, conceptually, they just required more grunt work. With git, I find people spend a non-negligible amount of time thinking about and dealing with the version control system. There are multiple ways of doing things and things that can lead to minor chaos. Older engineers need a fair amount of retraining. That said, I generally like git and I'm glad I made it through the painful learning process(painful moreso because I'm old). Now that I'm back using Perforce, I really miss some of git's basic functionality(and I'm working on wrapper scripts to reimplement it. Yeah I know about git-p4).
This article hit one of my biggest pet peeves - conflating GitHub with git. No, rebase, commit, pull etc are _not_ “GitHub” commands.
It also seemed to dissuade users from taking their git history seriously. Acting like Git is super confusing helps nobody. Don’t get me wrong, it _is_ confusing at first, but taking on that mentality only holds you back. Case in point: the number of coworkers I have who are afraid to rebase their dev branch onto master. It’s no harder than a merge, yet some people are terrified of it.
—
The rest of the advice is fine, albeit a little cliche.
Rebases are frequently much harder than merges if there's any conflicts. Rebases means replaying your commits on a different base. If you have multiple commits to an area of the code which is different in the new base, you'll be resolving conflicts repeatedly. Depending on how much work and how many commits in your dev branch, it can easily get to be more effort than it's worth.
IMO a clean commit tree that looks pretty and doesn't have repeated merges of the updated base branch is severely overrated, particularly in a team environment. If you've ever pushed your dev branch and you rebase, you've probably made someone else's day miserable, maybe not today, but some day very soon.
If you have someone dedicated to nice git history, and lock down your git server with sufficient hooks to ensure whichever branch you want to have a beautiful history has one, perhaps it can be made to work. I don't really see the upside.
Source control is occasionally - not often, but occasionally - useful for going back in time. Mostly it's useful for avoiding conflict in the face of concurrent commits, and for finding out why a particular line of code was written (we put JIRA task ids in every commit message). But even with the time travelling, all you need is something you can traverse. How pretty it looks isn't very functional.
Git brought a whole new way of thinking about versioning to the masses. There are many concepts in git that were probably never encountered before in many people's careers. Combine that with the confusing git user interface and people are left feeling bewildered. Prior to git, you didn't have to spend a lot of time understanding your version control system. You learned a few commands and it just worked. Yes, many things were more work to accomplish, but they were simple, conceptually, they just required more grunt work. With git, I find people spend a non-negligible amount of time thinking about and dealing with the version control system. There are multiple ways of doing things and things that can lead to minor chaos. Older engineers need a fair amount of retraining. That said, I generally like git and I'm glad I made it through the painful learning process(painful moreso because I'm old). Now that I'm back using Perforce, I really miss some of git's basic functionality(and I'm working on wrapper scripts to reimplement it. Yeah I know about git-p4).
Hard to detect, but this is satire based on the "THE tech lead" youtube channel.
Github is not Git. There are no Github 'commands'.
If the author makes a glaring issue as large as this, how am I supposed to trust the rest of the article's advice?
You don't. It's a medium article, they should rarely be trusted unless from a well established author.