Git Commands You Should Never Use

https://mquettan.medium.com/3-git-commands-you-should-never-use-99f6ec910989

by kiyanwang • 6 years ago

23 25 6 years ago

mquettan.medium.com

Rebasing, and thus git rebase, is a standard step that predates git.

The typical workflow is that you create a branch off master and do your work on it. Once thw work is complete is rebase the branch if master has changed so that you can test and review independently, then perform a trivial merge.

pickledcods• 6 years ago

The epiphany I experienced with rebasing is that this is an incorrect visualisation of the workflow. It's not like you create a separate branch and work independent of master. It's more like working on a kind of local pre-release ahead of master.

You work on the development/pre-release, then consolidate by cherry-picking or otherwise, leaving all the todo's, spinoffs, experimental, personal notes in the pre-release. Like a reptile shedding its skin.

cmwelsh• 6 years ago

It was the default workflow when people used to share patch files as attachments on community forums. You could only diff your changes to the latest tip and send these changes to the maintainer as a “fast forward” merge. If the patch broke, you fixed it locally (rebase) and attached a new version for the maintainers to apply.

huy-nguyen• 6 years ago

Rebasing is very useful. For example, GitHub allows you to require that branches are “up to date” with (i.e. being direct children of) master before merging. This ensures that all changes team members makes in PRs are made against the latest version of master.

Rychard• 6 years ago

Rebase isn't the only solution for such scenarios. Merging remote/master into the source branch will serve the same purpose.

theamk• 6 years ago

This depends on read/write ratio of your code.

If your projects is mostly write-only, merging master into branch is the way to go. This keeps entry bar low, and team velocity high.

If you expect many people to read project’s history, it is worth learning how to rebase so that each individual commit has a clear purpose and can be understood standalone. A few minutes taken by rebase will save many much more time of your future source code readers.

Topgamer7• 6 years ago

Click bait title. Understand the requirements. Learn the commands capabilities and drawbacks. Implement as needed. Rebasing can be superbly useful, and submodules can too. Which I utilize both to great success. Don't give me this "never use" bull shit.

spicybright2• 6 years ago

You don't have to be an expert in git to use these properly, especially re-base. If you find yourself arguing with Git most of the time, I recommend doing this:

1. Get a good night's sleep and wake up early, pour yourself a nice cup of coffee or your favorite beverage.

2. Open a copy of ProGit (free here: https://git-scm.com/book/en/v2) and read it cover to cover, while using something like Learn Git Branching (https://learngitbranching.js.org/) to try out what you're learning to get a better understanding.

3. Take a few walks and do your best to read the book cover to cover in a day.

4. Get a good night's sleep to cement the information in.

Git is not simple, but it's very powerful. But I also believe it doesn't take much to become an "expert" (if you already know how to edit text files and know basic command line usage + syntax). I don't think it's a lot to ask to block out a day or two to learn how it really works (at the very least chapter 10 in ProGit, Internals).

I see too many engineers arguing against git from a lack of understanding what commands actually do. Like it or not it's a corner stone of modern software development, and for some good reasons too.

wegs• 6 years ago

Nit: git is simple AND powerful.

Simple isn't the same as easy.

git is simple in the same way Lisp is simple, or Go is simple. git was hacked together in a couple weekends precisely because it's so incredibly simple. There are a few guides where you can write a git in a weekend (e.g. https://wyag.thb.lt/).

Really understanding git is really difficult, though.

A few years after you build a git, you'll get git. I've met only a handful of developers who really grok git, deeply, but it's a journey well worth taking.

The good news is that the surface understanding of git, from having built one, is enough to safely work with the complex commands that trip up most programmers. That's worth a weekend in itself.

kazinator• 6 years ago

Git was written by a notable "super-star" programmer, who also had a good understanding of and interest in existing advanced version control systems, and in managing integration flows in a large project with many third party contributions.

spicybright2• 6 years ago

Very good nit pick, that exactly what I was trying to express, thank you.

I think I was trying to say git is dead simple under the hood, but has lots of useful layers built on top.

One thing beginners trip over a lot I find, is there's lots of ways to do things, and some of those ways overlap, which can be confusing if you don't know what's under the hood.

dusted• 6 years ago

Interestingly, I would switched two of those commands around.

NEVER EVER USE GIT MERGE! IT IS THE EVIL ONE! MERGE COMMITS ARE DEVILSPAWN AND MUCH BE CLEANSED WITH FIRE!!

Git rebase is great though, even if I usually prefer just to reset and cherry-pick.

My and my gits are headless most of the time anyway.

Nginx487• 6 years ago

"Git submodule". Did not even read further, author does not have an idea how to manage VCS

igornadj• 6 years ago

Rebase is only dangerous and problematic if your team shares ownership of feature branches. I have yet to work at a place where that is the case.

I have, however, seen many git trees that are a complete mess to grok because of merges into feature branches.

disgruntledphd23• 6 years ago

Yeah, 23 commits into master from one feature branch is not normally a great idea.

When I worked at a large FAANG they enforced only one commit from a feature branch into master. I didn't realise why that was a good idea until I saw the alternatives ;)

matt-attack2• 6 years ago

Can you explain “commits into master”? I thought you make a feature branch, do countless commits to it, then either merge or rebase into master. Where does the number of commits into master come Into play?

matt-attack2• 6 years ago

How should more than one person collaborate on a new feature?

jamil7• 6 years ago

Ideally the feature can be split into more granular components that individuals can work on.

naetius• 6 years ago

Having to use my browser porn mode just to be able to read a simple post on Medium is a testament to how we should get rid of Medium before ranting about Git.

putsjoe• 6 years ago

Not sure what browser you use, but since disabling JavaScript for Medium (Chrome) it's been better.

I agree with you still though.

Git Commands You Should Never Use

Related Stories