Hacker News Reader

I don't have a solution and maybe the problem is just not solvable but ...

The tragedy is that git is so hard to learn. Start a github project (I know github is not git). Take a PR, have the PR have a conflict, now, try to explain to the new user how they can fix their PR via git to not conflict. You'll be stuck giving them a giant lesson, probably an hour to write the instructions, then several back and forths.

Mostly, either they already know git and fix it themselves OR I give up and merge it by hand myself since it's easier than becoming a git teacher for them.

> Take a PR, have the PR have a conflict, now, try to explain to the new user how they can fix their PR via git to not conflict.

Is this a Git problem? I recall entire workdays being wasted on SVN and CVS back in the day with multiple people trying to make sense of a merge.

In Git this is actually easier to do (and easier to do repeatedly, with git rerere and similar).

It's a problem, and the place to fix it is in git. That makes it a git problem. Just because things were worse back in the day doesn't mean we can't have nice things.

What puzzles me is how resistant many developers are to using or even considering a Git GUI. I prefer SmartGit, but GitKraken is nice too.

People tell me, "I'm so much more productive on the command line" and then it turns out all they know is pull/commit/push and using a local branch. Anything outside that brings terror: "I never use rebase. What if something goes wrong in the rebase? Now I've lost all my work and I have to pull a fresh copy of the repo from scratch."

Yes, I have heard exactly that.

One thing I love about SmartGit is how it unifies features that the Git command line presents as separate and unrelated concepts. The reflog? Click the Recyclable Commits checkbox and now all of your reflog commits show up as ordinary commits just like any other.

Stashes? Same thing. Turn on the checkbox to make a stash or all stashes visible and now they show up as ordinary commits, which is all they are under the hood.

Want a diff between two commits, whether they be normal commits or stash or reflog commits? Click one commit, ctrl+click the other, and you instantly see the differences between the two. No need to check out a reflog commit temporarily just to have a look at it.

Yet I have only had a 5-10% success rate in getting anyone to take a look at any Git GUI, much less using one. I would be really interested in understanding why so many developers are reluctant to doing anything other than the Git command line.

I agree with your assessment. I think GUIs are great things that you don't do often enough to memorize (or for things that are inherintly visual, but not relevant here) but they are often looked down on.

There are many people who do enough git to know how it works well and be familiar enough with enough of the commands that they don't need a GUI and are likely faster on the command line. But for every one of those people there are at least 2 who would work faster, and more accurately with a good GUI.

> SmartGit […] GitKraken

> I would be really interested in understanding why so many developers are reluctant to doing anything other than the Git command line.

In the spirit of curiosity, I downloaded the two packages. SmartGit shows me a document and outright threatens me to "deactivate". https://www.syntevo.com/blog/?p=4148 This is a euphemism for other people coming to my computer and deciding what I am able to do or not. I declined here. GitKraken shows a log-in screen before letting me use the software properly. It does not refer to the account I already have on my operating system and which is entirely under my control, but some other account which is under the control of other people. That account could be revoked at any time without my say in the matter and then I would not be able to use the software, on the face of it that's the purpose of the log-in screen. I declined here. As such, I did not even run the central part of the two software packages and cannot tell my opinion how well it would work, but I already learned what I needed to know.

I object to other people desiring to restrict how I use a software. This is fundamentally not compatible with my view on how I want to run my life, and that software/the people responsible for it have no business telling me. I will never consider these packages again. The software I have been using for years, namely qgit (a GUI) and the command-line tools, impose no such restriction.

> Edit: My practical advice: If you use git every day and you don't know how to rebase, reset, cherrypick, and stash from the command line, make it a goal. Then, once you're comfortable, learn how to do it in a visual tool like Gitkraken and make an effort to incorporate them in to your daily workflow. My guess is things will become a lot less tedious and confusing when things get messy.

I would add git bisect to the list. It's incredibly useful (if your codebase is sane).

I read some description ob what that is and it looks like checking out different commits (via bisection) until you figure out where in the history some change happened. Is there some other benefit I am missing?

It automatically does a binary search, and you can use it completely automatically if you can write a script that determines if the bug was present.

The other day I used it to write a good bug report. I first used it to find the earliest commit I could compile on my machine, then I used it to find the commit where a certain command would fail.

It's not about finding a particular change, it's about which change broke something.

In the best cases, it's totally automatic. You know that it worked at commit A and is broken by commit Z. So it checks out commit M and runs the tests. If they succeed, then it broke somewhere between M and Z. If they fail, then it broke somewhere between A and M. So it checks out either H or S, depending, and repeat.

It's not always that easy, especially when your tests and environment are complicated. There's often manual intervention, which is tedious. Still, log2 N steps is often manageable, especially if the computer is taking care of the tracking for you.

Thank you (and the sibling) for the explanation, sounds useful!

I know how to rebase, reset, cherry-pick, stash, reflog, assume-unchanged, and many other advanced techniques.

I still prefer to add/commit/branch/merge. I often copy-paste changes into a new branch, just because I don't enjoy recalling arcane commands from memory or googling them for the umpteenth time.

I suspect that git is a leaky abstraction that doesn't fit the corporate software development workflow. I think that git is a hammer and non-distributed development is the screw we're hitting with it.

True, but you could also argue the opposite view that it's a sign of git's usability that beginners can get by with just those commands. The problem doesn't crop up until those lazy users start doing things that make the repo messy.

That's honestly the opposite of good design. It's hiding the complexity to make it seem easy for beginners, then slamming them with inscrutable error messages when they "don't use it right." It leads to a system with a deceptively gentle learning curve that requires you to suddenly learn everything all at once when you hit an issue.

Good point. I'm not sure which side I'm on, to me git feels like a good core with an atrocious UI, even after years of use I have to look up whether to use this or that option and whether it's uppercase or lowercase, do I use "--" or ":" and on and on.

Mind you, I'm not complaining, most utilities I've written for my internal users are worse! It's when something gets out and used by the masses that you wish you had had the time to put together a coherent user interface.

It's really just using the old generic version control commands everyones used to.

Rebasing and cherry-picking are awesome tools once you know how what they're actually doing. I think people avoid rebase for a few reasons; the term "rebase" doesn't mean anything outside of Git so it's not obvious what it is doing under the hood, and inexperienced Git users might use it to change the history on the main branch, which I see as an antipattern.

There's nothing inherently wrong with merging, but I personally don't like it because I find merge commits harder to understand than regular commits. Better to use things like rebasing and cherry-picking to move commits arbitrarily and then squash some commits into units of work that make sense.

Stash is crappy though, IMO, because it's not branch-specific. Instead of stash, I like to fork the branch I'm working on and create a "WIP" commit. That way I don't lose track of work I had in progress that only belongs in a certain branch.

> the term "rebase" doesn't mean anything outside of Git so it's not obvious what it is doing under the hood

Read "base" as "baseline"; that should help significantly for the simplest use of rebasing a series of commits without changing them.

I think it's a tragedy that just about every developer uses git but most learn add, commit, branch, and merge and then just stop learning.

This implies that they think in a wrong way and not have a wrong tool. A real tragedy is that git took over the world (in minds of lovers of shiny-new things and in saas) without most of the world realizing that they don’t even need it, because they wouldn’t even like to think in its way. The world wanted quick subversion and instead got this in-all-regards UX monster.

In practice, rebasing increases conflicts, requires teams to time their merges, and obfuscates the history of the project.

I never understood why people think this is a good pattern.

In a large repo with many people merging, it helps keep things organized.

In my experience you can make an argument for a merge-based workflow up to around 6 people. By 12 it's painful and hard to track what's going on, doubly so when you have a dev branch and multiple sustaining branches or something more complicated.

By the time you get to 100 people or more committing to the same repo, it just becomes absolute chaos, and at least you can maintain a semblance of sanity in your official branches by forcing a rebase-based workflow on them.

I feel like it’s one of these moments when people speak of git and everyone has their own version of the manual. git-rebase:

git rebase master; Now, the snapshot pointed to by C4' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history.

What does it even mean to have a rebase-based workflow? In svn-like terms, does it mean that you have to sync-merge before reintegrate-merging? If yes, why is rebase stated as if something completely non-existent before and reinvented? You do sync-merge before reintegrating in svn, otherwise you’ll apply ancient-based patches to the young trunk, which is obviously not what you want.

And if you do not use rebase, but use a merge-based workflow, does it mean that you apply ancient-based patches to the master? If yes, of course it will be a conflict hell, cause master could undergo few refactorings in the meantime.

It is so confusing when people talk in a different slang, and you can’t tell if they invented something new or just missed something so damn obvious in the old tech. Can you please comment on which of these thoughts are [in]correct?

It's not exactly congruent to what you're describing with SVN. It's all about the DAG of commits and how we're using it to describe the history of the codebase. The end code is identical between the two workflows.

A merge-based workflow maintains the work-in-progress history of commits running parallel to main before merging the two together. So your commit tree splits and reforms, with the number of branches at any one time equal to the number of people working on distinct features at one time.

It shows you how a feature evolved, which there is some benefit of, but at the cost of an explosion in branches that are now part of the permanent record of your codebase and the main branch you're working in. It rapidly turns into spaghetti with even just a few people working in the repo.

A rebase-based workflow will typically compress all the work in progress to a single commit, which then gets applied to the tip of the main branch. This maintains a linear flow of commits where each commit is a single PR.

Maintaining that linear flow of commits is increasingly important as the number of people committing to the repo rises and the branches rise with them.

Visually, a merge-based workflow might look like this:

   4
   |\
   | \
  /3  \
 | 2\  |
  \| |/
   |//
   |/
   1

This would represent 3 features worked on by different people, all branched off the same source (1), and then merging back in.

The same thing in a rebase-based workflow would look like this:

All of the work in progress is collapsed into a single commit when completing the PR to maintain the linear history. Of course while it was in progress, it resembled the merge-based workflow above. The difference is that instead of merging at the end, they rebased and squashed the commits.

Again, the end result in terms of the code is the same. The difference is what you see when you're navigating the history of the repo.

Thanks for taking time on such detailed explanation! So, the benefit of rebase is in a graph view of the repo, not in a conflict resolving workflow (which is consistent with the manual). But why

merge-based ... rapidly turns into spaghetti with even just a few people working in the repo

Isn’t it just a detail of how graph/report tools work? Can’t they track these merge points and “rebase in their ram”? I don’t get how a graphical representation of merge points may change the workflow.

One more thing that is unclear is why some people think that rebase is somehow superior in terms if conflict and reintegration. Like they “had issues with svn and now that rebase is a thing, issues gone”. Maybe they didn’t understand that you have to sync-merge your branches (effectively rebasing) periodically to not diverge from trunk (or parent branch) too much?

Added: I know rebase is not congruent with what I’m asking, but my questions are more about how git folks think, not about how git works. Cause I often see its comparison to other VCSs and claims that are vaguely or simply untrue about git competitors. As if before git there was some stoneage.

It is a detail of how the graph is stored and viewed, but you'll be looking at that graph when bisecting searching for when a regression occurred, or how a particular feature came to be, or when a particular feature landed.

The repo rapidly turns into spaghetti with a merge-based workflow because all the work in progress is now part of the historical record for any particular commit to main. You're not looking at a single commit, you're looking at a chain of commits and a merge node. Now imagine there are 20 people committing to the same repo. Your branch factor is exploding! Imagine the picture of my merge-based workflow, but multiplied 7. It rapidly becomes very difficult to navigate.

The DAG is important as a historical record because you have to go back to it on a very regular basis.

It doesn't change the workflow from a "do your work and commit to the repo, periodically sync with main" perspective. It changes the workflow from a pull request perspective.

I've found rebase is (slightly) inferior for conflict resolution and reintegration--mainly because unless you squash your commits down to a single commit, you may need to resolve the same conflict as many times as you have commits after the conflict in the worst case, which is irritating. Merge is just one and done. But that's a minor thing.

Having used SVN (briefly) and Mercurial (a lot) and Git (a lot), SVN pushes you into dealing with a single linear history of commits, with cross-branch merges being extremely painful and error-prone if anyone else has worked in the same area. DVCS like Mercurial and Git allow you to do whatever you like for the history, and cross-branch merges are generally easy and pain-free. I can't say anything about the underlying implementations and why it is that way, but that is my lived experience.

Most of the time with Mercurial and Git I can let the merge tool resolve differences if there are conflicts with the odd line needing manual intervention. Most of the time there aren't conflicts.

And having used SVN a bit...yeah, it's the stone age in comparison. Sometimes you have to make that tradeoff because you can't store everything locally, but I haven't enjoyed the times I've had to use SVN after having used Mercurial and Git.

And Git's user interface sucks.

I need a Mercurial skin on top of Git so the commands make sense.

Thinking about this further, SVN forces history to be a linear history of commits, which is easy to reason about.

DVCS have a DAG of commits, which can get arbitrarily complicated and difficult to reason about.

Rebase-based workflow results in a linear history of commits, which is easy to reason about.

Merge-based workflow results in an arbitrarily complicated DAG of commits which is difficult to reason about.

That's all there is to it.

What you need to understand is people use rebase on their unshared branches. It's part of crafting your commit history to be a coherent set of atomic changes instead of the path you took while developing it all.

You rebase BEFORE you merge into the mainline branch.

Do you run your test suite against each of the commits you create when rebasing? If not, isn’t this “coherent set of atomic changes” misleading? It seems like a lot of effort to make a fake clean-looking history.

There shouldn't be an issue in doing so. During a rebase you'll either have no conflicts — in which case there isn't an issue — or you'll have to stop to resolve conflicts, and you might as well run tests before continuing the rebase. In both cases I'd argue that the statement "coherent set of atomic changes" applies.

Correct me if I’m missing something here - but a lack of conflicts during rebase only means that the few lines surrounding your changes weren’t changed in the upstream. The rest of the repo changed, and this will often cause some kind of inconsistent state. I’ve encountered this situation frequently when using git bisect.

When you rebase, you basically replay the history of your branch since it diverged from the branch you're rebasing onto. Thus, the branch is always in a consistent state (or equally consistent to when you originally authored the commit you're replaying). And of course this assumes the target branch is already in a consistent state.

If the upstream is like this:

A -> B

And you branch off B and start making changes, then the upstream continues on its own:

A -> B -> C -> D

Now you rebase your dev branch off D. Your changes get replayed on top of D and create new commits. Some of those commits might not be valid, because they take code that worked in the context of B and put it in the context of D. The history seems clean if all you do is look at the diffs, but if you bisect and try to use the repo in one of the rewritten commits, you may find it doesn’t even compile (even if that commit was fully functional before rebasing).

Hm, you're right. The simplest example I could think of right now is the upstream having renamed/deleted something that the dev branch depends on, but didn't directly touch. That would definitely cause a "broken" history during the rebased commits, and is technically unavoidable.

A surprisingly common occurrence is two developers independently notice and fix the same problem, but they implement the fix in two different ways. The diffs might not conflict at all during a rebase. Or they might only conflict in some places, and the “behavioral conflict” remains after the diff conflict is resolved. This issue would eventually be noticed and fixed when tests fail before merging to master, but the intermediate rewritten commits are unlikely to be fixed.

I can see this happening, but with a reasonable bug-tracking solution in place and enforcing `fix/...` branches for fixes, these situations could mostly be avoided.

When I've done this, your private/dev branch may be a series of broken commits. Then you rebase onto main, squash to one commit, and test (if necessary). So what shows up on the main branch is a single, squashed, tested commit that contains one logical unit of code (usually a feature or fix).

In this model the main branch history is "real" in that it records the sequence of changes to the production code. It's "fake" in that it doesn't record the exact sequence of fumbling steps and backtracks you took to get there. But IME the latter is usually not very useful anyway.

I like the squashed commit approach. I get there by merging upstream into my dev branch when developing, then squashing before I merge my changes into the upstream. As far as I can tell, that has the same outcome as rebase with squash. Both approaches create a simple commit graph, and both avoid fake intermediate commits.

In some cases I agree, but squashes can end up so large that doing a `git bisect` (which is quite useful in finding the comparatively small commit which introduced a bug) becomes unfeasible.

For sure, I understand that.

It tends not to be an issue when a developer is working on an isolated feature that only he or she cares about, that is reviewed in a timely matter, and gets directly committed to main.

Often this is not the case.

This. I don't know if it's because of a lack of understanding or bad workflow, but almost all of the times I've seen bugs caused by git operations to slip through the cracks, it's been because someone decided that a pretty history was of upmost priority. Rebasing is probably necessary in some cases, but it can be a real foot gun as well.

Honestly, I don’t really see your point. Yes, We keep our commit messages as clean and descriptive as possible. Yes, if we have the time, we split our commits into logical groups of changes. Yes, we work on feature branches for mature projects. We do all this with the git integration of IntelliJ, and I don’t see the slightest reason to waste any time with the syntax of our version control tool! I’d gladly force everyone on the team to use „stuff“ as the single, exclusive commit message, if that improved velocity (which it obviously doesn’t). Because all this discussion about proper git usage is nothing but bike-shedding.

It's also one of the few tools that is likely to be a constant factor in your job for a long time. Yes, it's not super easy, and you can sort of get by with minimal effort, but it's not that much time to invest compared to how much benefit you'll reap.

And I don't mean memorising commands and their arguments, but rather understanding Git from first principles.

(I wrote this visual tutorial for that purpose, takes about fifteen minutes to go through : https://agripongit.vincenttunru.com/)

This looks nice but scrolling on Safari on Big Sur is causing weird artifacts. maybe if I scroll really slow

Ah sorry about that; unfortunately Safari doesn't support any of the systems that I own, so I can't test on it, and it seems to work fine on the WebKit browser I do have...

Be safe out there everyone. Squash with caution, don't force push master. And remember, reflog is always there to help if you get into trouble.

Agreed. Git should be treated as a deep skill, as important to practice and train with as unit testing and regular expressions.

Think of your git history as a product and art form in itself. If you don’t enjoy writing your commit history, readers will not enjoy reading it.

On a tactical level, I highly recommend buying Sublime Merge 2.

Regular expressions? I really enjoy using them and futzing around but I encourage the people I work with to stay away and to avoid using in production when possible.

Regular expressions are useful as tools for searching through code, filtering logs, searching through the filesystem..., even if you never commit them into your codebase.

Yes, good clarification. I probably write 10x (maybe 100x? more?) more throwaway regexes than regexes I commit.

Whoa, why? That sounds like an awful advice to me. By all means, use regexes, but make sure you understand the theory behind them (state machines) so you will know not to parse HTML with them. They are really pretty easy to do right once you grasp the concepts.

You can write correct ad hoc regex parsers for many subsets of HTML depending upon your needs.

I found Sublime Merge -- although it may have been version 1 when I tried it! -- very unintuitive and fiddly, a lot like using Vim for doing three-way merges. Definitely one of those "YMMV" kinds of tools. (I mean, I'm sure Vim is terrific at it once you get the hang of it.)

Personally, I've settled on

* Getting pretty familiar with the git command line

* Using a decent GUI diff and three-way merge tool (I use Kaleidoscope)

* Using GitUp, an open source Mac git client, on occasions where I want to get kind of arcane: committing individual lines of files in separate commits, re-ordering commits (on an unmerged feature branch because I'm not a complete monster), etc.

I suspect having already discovered GitUp is a good chunk of why I didn't get into Sublime Merge; it can do a lot of advanced stuff in ways I personally find easier to grok.

Alternative interpretation: git is a terrible terrible tool. It solve's Linus' problem, but he also wrote the damn thing. Had GitHub not entered the scene we'd likely all be using something else, maybe even SVN still.

Maybe distributed source control really is this complicated and treating git as a deep skill is justified, but having also used Darcs and Mercurial I have a hard time believing that git's usability issues are inherent complexity and are in fact an artifact of git itself.

> My practical advice: If you use git every day and you don't know how to rebase, reset, cherrypick, and stash from the command line, make it a goal. Then, once you're comfortable, learn how to do it in a visual tool like Gitkraken and make an effort to incorporate them in to your daily workflow.

I do agree you should learn rebase, reset, cherrypick and stash, but I don't agree that you need to learn on the CLI. I mean, use the CLI if you prefer that, but the git GUIs are perfectly adequate for performing any of these operations.

I used to use git CLI heavily, but in the past few years I have simply not needed to, to the point that aside from a small handful of the most common operations I don't even remember a lot of it anymore. Partly this is due to maturity of the GUIs, and partly because old practices like SSHing to a dev server to edit+commit something there are just totally obsolete and unnecessary these days.

Even for a simple commit, there's a massive convenience of seeing the timeline and being able to interactively stage and look at diffs that is just miles ahead of CLI, and lets me break down commits into better units of work and write better messages.

There's a stupid gatekeeping thing some developers still do about git CLI, I don't get it. It's as valid as dictating what text editors, color schemes, input devices, or OSes "real developers" use. Judge people on their output, not their tools.

I don't force my choice on others, but I'm firmly in "git cli" camp. The reason is simple - cli is available everywhere. I'm sure GitKraken & co. are great once you get used to them, but apart from GitLab graph view (which GitHub sadly lacks, and cli tool afaik also) I don't miss anything. But again, this is just my personal preference and I agree that developers should be free to use gui if they prefer it.

> cli is available everywhere

I guess that's part of what I was getting at though. Where are you doing your development that isn't your workstation?

I work on a whole bunch of different things -- from personal stuff running on my laptop or VMs in my house to cloud services deployed across dozens of AWS services -- and things have just got to a point where I have no need to do a commit anywhere but my workstation. (Well, technically, I have two: one personal, one work).

I definitely used to do it years ago, but now I don't remember the last time I had to use git on a remote system.

I use two at the moment but they change over time, along with the OS. I am not talking about developing remotely, though it does happen that I use git push to deploy for some smaller projects. But I could have used GUI for that too. I guess I just don't want to get used to a tool I won't be able to keep using.

I avoid rebase because it rewrites history, and I'd rather have an accurate log of what happened. Cherry-pick can certainly be useful for grabbing particular commits; although I find myself more often using `format-patch`+`am` to grab particular files (which also works across repos).

I use rebase often because it rewrites history - it lets me squash commits into a conceptual single commit, or re-order commits together that chronologically make more sense next to each other.

I never understood the "rewrites history" argument. The original commits don't necessarily faithfully represent my thought process, I might have a larger commit because I got distracted in the middle of the day or a shorter commit because I wanted to make sure my code was backed up at the end of the day.

I think the issue here is that using git is not a goal unto itself. Git is a tool/system that should get out of your way as much as possible. Instead it has arcane commands and options making anything but the most basic operations Shakespeare novels on the command line.

My goal is to have my code in the repo. So if git starts being a pain, it’s much easier to store my edits locally, pull a fresh copy of the repo, copy over my edits again and commit + push.

If you have a good cook, let him/her cook dishes and let someone else care about sharpening the knives and cleaning the dishes.

If you have a brilliant programmer, let him/her write good code. Don’t bother them with understanding binary trees and hashes of snapshots of diffs of local repo’s of pointers of objects in a blob graph lalalalala.

My usual workflow is to frequently merge master into my feature branch during development, then I squash before merging back to master. As far as I can tell, this gives a clean history so shouldn’t bother the rebase fans (who prioritize a simple commit graph), and shouldn’t bother bisect fans (who get confused by fake historical commits). Is there something bad about this approach?

> I think it's a tragedy that just about every developer uses git but most learn add, commit, branch, and merge and then just stop learning.

This is because Git is too hard to use.

How do I know that Git is too hard to use? Because there are literally thousands of blog post tutorials explaining how easy Git is to learn. Things that are easy do not need thousands of different guides telling you how easy it is.

> This is because Git is too hard to use.

> How do I know that Git is too hard to use? Because there are literally thousands of blog post tutorials explaining how easy Git is to learn. Things that are easy do not need thousands of different guides telling you how easy it is.

I'm not sure that's convincing. I think that a lot of guides about how easy it is indicate that it's slightly difficult to learn. That results in a lot of people struggling for a little bit, overcoming the struggle, and feeling a sense of accomplishment and enlightenment, which they then want to share.

(There's also a difference between how hard something is to use and how hard it is to learn. I'd argue that there's often a trade-off to be made, where some sacrifice on difficulty learning results in a reward in ease of use—in the sense that, for example, vim is far easier to use than any other editor for a seasoned vimmer.)

The counter argument would be that maybe git is so basic and easy to learn that everyone feels comfortable enough with it to write a tutorial?

I think a large amount of content is more a factor of Git's ubiquity than its difficulty.

> git is so basic and easy to learn that everyone feels comfortable enough with it to write a tutorial?

Nobody writes tutorials on how easy Lyft or Uber apps are to use. Easy interfaces don't need lots and lots of tutorials. That's exclusively the result of poorly designed interfaces AND complicated systems.

Lyft is an app. Git is a tool for developers. I have no clue how they're related.

That being said, I googled "How to use Lyft" and there's a ton of results.

> Lyft is an app. Git is a tool for developers. I have no clue how they're related.

Google: What is a system

Good luck.

My SCM journey: RCS-PVCS-cvs-VSS-MKSSI-svn-Perforce-git

I hate all of them but learned to use them because what's the alternative?

I respectfully disagree on the basis that, yes revision control is hard, but git provides a relatively beautifully simple api and vocabulary on top of an inherently complex and absolutely necessary set of concepts.

When you're working on a codebase with multiple people, there are going to be changes and the changes have to be consolidated and the conflicts have to be resolved. I believe, with a reasonable amount of time and effort, developers can learn that API and vocabulary and I have yet to encounter anything comparable in terms of ease of use and "grok-ability" - especially with modern GUI tools.

git is one of the most ubiquitous and unavoidable technologies in software development and it's 100% worth the time and effort to understand and be good at it.

> This is because Git is too hard to use.

Git is hard to LEARN. It is objectively very easy to USE for those who have learned it, so much so that the population of "I used to use git until I found ..." evangelists is effectively zero. Tools like mercurial exist in the marketplace of ideas mostly by peeling off users who haven't yet started using git productively by promising 80% of the features for 10% of the effort.

In fact, I don't know that there has been a new tool since vim or emacs that so well illustrated this dichotomy between ease of learning and ease of use.

But to be honest: it really is needlessly hard to learn. The content of the linked article is that git is built on an extremely simple foundation of data structures and operations that anyone can understand. But the takeaway from the article is that no one does understand it, because that layer is hidden behind a facade of tools that completely obscure it. Where are the "blobs" in git reset? What is the "index"? Is it a "tree" (it's not, IIRC)? I definitely agree with people who complain about the porcelain layer's design. But I still use git every day and love it.

You have evidence that git is hard to use, but no evidence establishing that it's too hard. Some things just aren't easy.

Git has over-complicated source control for the majority of developers. Things were much simpler with svn.

> Things were much simpler with svn.

Not from my experience as a newbie with SVN at the start of uni and in the beginning at $job.

In both cases, it was temperamental, prone to network issues (this was in both student accom. -> uni server, and LAN at $job) and did not like users working on the same files.

Git took some learning, and it took reading Git Magic <http://www-cs-students.stanford.edu/~blynn/gitmagic/> to go from <https://xkcd.com/1597/> to the friend mentioned in the alt text.

SVN still feels like I'm pulling teeth all these years later.

SVN is a versioned storage engine pretending to be source control. Branching and tagging? We'll just expect everyone to obey an implied policy in our filesystem tree. Oh you think you want to merge these things that have a clear ancestor in the DAG? Not so fast buddy.

IIRC, merging in SVN is... basically something you never wanted to do. :)

Svn's complete inability to handle merges at a file level may have been simpler, but was by no means better. Needing to coordinate who is allowed to edit each file in order to avoid a painful merge is common with svn, and nearly unheard of with git. Svn looks at the inherent complexity of multiple people working on the same code base, shrugs, and figures that it is somebody else's problem.

> My practical advice: If you use git every day and you don't know how to rebase, reset, cherrypick, and stash from the command line, make it a goal.

I couldn't agree more. It's not only enabling more sensible interactions with the people that collaborate on repositories with you, it's also a comfort that allows to experiment and take benefit of the tool without fear of getting stuck.

I would add checking the reflog and how to use it to complete the list, even if it's clearly less important.

A source that I recommend wholeheartedly for those that want to go further down the git rabbit hole: https://learngitbranching.js.org/

How do you track which cherry picks have been done?

We've never had an issue with git merge'ing all over. I've never looked at our git graph because I've never had to.

Maybe rebase is a tool to help poor software development practices? (and your colleagues letting branches go stale is one of those)

I agree if you merge early and often everything goes smooth and if you have a stale branch your doing something else wrong. At least for the work I do, web dev. Some of our pipeline folks are working under a different paradigm and they run into these problems often but also understand how to rebase and cherry pick. As always just depends,

> help poor software development practices

Says someone who's "never looked at our git graph".

Entertain me then, why do you need to look at it?

> about every developer uses git but most learn add, commit, branch, and merge and then just stop learning.

What are branch and merge? /j

> A lot of people are scared of rebase and cherrypick and shut down or get defensive when you mention them or try to encourage their use.

Because a lot of people have been burned and way too many hours been lost due to a rebase gone wrong. Cherry-pick and stash are trivial operations, reset (outside of "undo a git add") and especially rebase are not.

The learning curve for both is steep, the potential for failure extremely high, so I understand why organizations go as far as entirely banning rebase.

People are scared of rebase because of the constant scare-mongering around it. "Rebase is Evil" and "Never use Rebase", etc. Then we end up with junior devs that are too-scared to even use their git IDE's built-in rebase-remote branch onto remote so they end up littering the entire repo with "Merged branch-A from origin into branch-A".

It's so bad that even seasoned developers that haven't delve deeply into git have no idea that this sort of rebase is practically harmless. Instead they parrot "Rebase is Evil" without thinking twice.