Git Commands You Should Never Use
mquettan.medium.com
mquettan.medium.com
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.
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.
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.
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.
With rebasing, it seems to me to be easier to maintain a clean history (no merge commits) since all merges end up being fast forward, with the added benefit that I can deal with any conflicts as and when they come up rather than fixing them all at once when I eventually merge to master.
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.
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.
I have, however, seen many git trees that are a complete mess to grok because of merges into feature branches.
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 ;)
Let’s say the cto has said no merge to master until after n days. I have a few defects that I need to work on that are in the same files. Ideally, one should make a different branch for each defect. However, I’ll have to deal with merge conflicts when I merge to master next week. So, I put multiple defects in the same branch and put tracking information in commit message for example
Use break word in result table
Since we allow first names to be up to a hundred characters in length, the table should stay within the constraints in its container even with a hundred no space characters For #4007
—
As you can imagine this isn’t ideal on multiple levels.
First, a merge request should only address one concern. That being said, the problem pretty much lies somewhere else.
The second follows the first. Assuming the first, we should be able to squash all commits in the feature branch without losing information.
I’m sure this is a common problem but I’ve not heard of a good solution to it so far. I’d love to hear what I should do differently.
This seems like the problem you should address first.
I imagine ideally we should use tags for release but for some reason we don't do that.
I agree with you still though.
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.