That is to say: I totally benefit from "git commit --amend && git push --force-with-lease" but 100% percent of the time want that flow to call time-out if someone has pushed before me
Unfortunately as UI a 7 character option is almost always going to win over an 18 character option. I know about --force-with-lease, I know that it would provide an extra safety guard, and I always use --force anyway because it's the short, easy to remember and quick to type one.
Check out --force-if-includes … it works well in combo with —-force-with-lease and ensures you don’t accidentally replace a branch that is not yet merged into your current branch (force-with-lease has a pitfall where if you fetch before pushing, it’ll act like a straight up force push).
Hi, I am the author of the "Git Purr " doodles here.
This probably isn't for everybody but if you like tech && cats, I made "HTTP Status Cats" a long time ago too. I believe that one satisfies more of you.
Just printed your doodles and put them on one of our whiteboards.
Most of my fellow devs are from a 3D modeling and design background and have a hard time understanding anything more than push and merge (using a GUI). I tried to explain them numerous time, but they just phase out after a couple of minutes.
While the doodles are cute and colorful, I fear you have to already comprehend the subject matter to appreciate them. This is doubly true since the doodles are in fact pages laden with quite a bit of text.
I doubt there is a target audience which fails to comprehend the un-doodlified versions of these doodles, and is helped significantly by the cats and colorfulness.
We own four cats in our household, aged 16-25. So they’ve been around almost as long as I can really remember. In all that time, anything I’ve been capable of doing I do much worse and much more slowly when they are present. Playing piano, cooking dinner, writing code.. all crumble in the face of a cat that wants a warm lap (and won’t shut up about it).
Understanding git doesn’t feel any different, just more extreme. Anyone who tells you that they fully understand git is mistaken, lying, or named Linus. How is adding cats going to fix that?
If only we could instead have an intuitive version control system which didn’t need crazy explanations or for each team to have a ‘git expert’ who has memorised a few more commands for unbreaking the repo than anyone else. But for now, it seems git is here to stay and many collective hours will be wasted cursing the git who designed it.
> If only we could instead have an intuitive version control system
What makes git any less intuitive compared to svn or cvs? To use either of those or git effectively required reading through documentation to understand what each command did.
I have no experience with those, but the complaint is that there are a myriad of commands and flags and overloads that could basically amount to a handful of common operations and simple resolutions.
I myself have “no issues” with git but conflict resolutions are still a guessing game when they’re for middle commits
Typically git is compared to mercurial which is quite similar in many ways, but feels much simpler. It's been a while since I have used mercurial but I enjoyed it a lot.
Svn and cvs are centralized, which makes everything much more intuitive and easier to understand IMO. I also think they are simpler (centralization requires less commands)
> Svn and cvs are centralized, which makes everything much more intuitive and easier to understand IMO.
For both cvs and svn, creating branches, merging changes from different branches, and switching branches definitely were operations that required a few steps that would not be easy to figure out without reading through the documentation.
The only thing that git had that those programs didn't was the concept of a staging area, which, as I understand it, bazaar and mercurial didn't have (unless you created another copy of the repo or another branch to serve as a staging area). But the fact that people have tried to replicate that feature in the other DVCSs indicates that it's a desired feature, even if it does add some complexity compared to not having it.
Me too, I use TortoiseGit almost exclusively. I have its log view open almost all the time and do all my git actions from there. I can get along in the command line but I'd rather not, my short term memory is awful.
I just like seeing the visual feedback of the actions I've just done.
This is one of those "explanations" where, if it's a concept I'm familiar with I can apply my knowledge to it and see that it mostly checks out, but if it's something I don't already know, I find completely useless.
Personally, as someone who has been sketchnoting for about 5 years, I feel the point of sketchnoting is more to create a condensed visual reference of an idea for personal recall than for teaching that same idea to someone else.
There's a wider argument here of whether notes should be used for personal recall or general reference. I tend to lean towards the former, but there's more nuance here.
I'm working on a blog post that discusses how to take good sketchnotes and breaks down this argument a lot further, but it's already super long and far from being finished... perhaps I'll finish it someday, haha.
Kudos to the original author of these notes. When taking these types of notes, you have to think about what to leave out as much as what to leave in. I think that concise notes in this style to show that the author has a deeper understanding of the subject than the notes convey on the surface, especially when the point of these notes are to compress one's knowledge on the subject into a concise visual representation.
Rebase is just replaying the diff associated with each commit. It’s like a batch cherry-pick and that itself might be a conceptually more straightforward place to start.
The most useful way for me to think about a rebase is "replay my commits over an updated branch, as though I started coding when those updates had already happened"
So if you check out on day 0 and rebase on day 5, then it becomes "pretend I started coding on day 5 in the first place, and let me correct any contradictions (conflicts) as though I was making those decisions as I was making each commit".
I still struggle but this helps me conceptualize it.
For me it's the other way around. I mean, it's like one of the few commands which says what it does: re-base. Makes all kind of sense to me: take what you have and put it on top of something else. So same as a bunch of cherry-picks, etc. It was one of the first concepts I undesrtood. Merge on the other hand I understand as well but it leads to graphs I can't understand without spending some time looking at.
Rebase means moving the branch point of your feature branch to later on the main branch.
Let's say you create feature branch foo from main on 2021-08-01. You do work. Others do work and add them to main. On 2021-09-18, you rebase foo onto main. This has the effect of re-writing history! There's no longer a branch point at 08-01, it's been moved to 09-18.
Rebase is not always the best option. I personally prefer merging, and that has worked for 100% of situations I've found myself in so far in my DevOps career.
> Someone will correct me, hopefully, if I'm wrong:
> Rebase means moving the branch point of your feature branch to later on the main branch.
It refers to a more generic action/set of actions, where this description is one possible end result. Granted this is probably the most common use, and the name "re-base" definitely fits this usage best.
The more generic action is something like "take a set of commits in one place in the git history, and reapply them somewhere else in the git history, optionally dropping or rearranging some of them in the process".
It's strangely wonderful to me that people can have so many different ways of explaining this action/concept. Your description is definitely more accurate than mine :)
Tip: Create a new branch before you do the rebase, if you fuck up the rebase with bad merges or dropped commits it's easier (i.e. more intuitive) to unfuck by just using the backup branch you made prior to your rebase instead of messing around with `git reflog`.
rebase cherry-picks more than one commit, as in "git reset c; for commit in a..b; do git cherry-pick $commit; done". With sensible defaults for a, b and c, they can often be left out.
My qualm with most available explanations back then were that they all start from command line with no visual explanation.
Now if you understand that it's a linked list, where nodes link to previous node instead of next, branches and tags and everything starts to make sense.
I was really disappointed when I saw this, but not because of the content, which is great, but because I saw Cats (Year) and assumed that the link was going to be explaining git using the _movie_ Cats. Sadly, the movie was Cats (2019).
I wonder if having Mercurial continue in python is a development advantage, or it just started out that way but now would benefit from a more performant version
- Introduction to Programming & Tools
- Machine Learning Regression
- Notes from Presenting Data & Information course by Edward Tufte
- Notes from The State of Web Platform
And her list of other Tech Doodlers & Sketchnote artists to follow (https://girliemac.com/blog/2021/07/12/microsoft-beginners-sk...).