9 ms·

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. A lot of people are

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. 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. The result is, because developers only have a hammer, they brute force merge everything which results in grotesque conflict resolutions and commit histories and makes it hard to untangle problems. At a previous job, another developer was kind enough to walk through rebasing on the command line with vim. I was receptive and in about 10 minutes, I realized there was a significant set of standard features and day to day Git use I was previously just oblivious to. These days, the UI for rebasing and cherry picking in Gitkraken is state of the art and effortless and I use them every day without hesitation and without the fear that comes from not understanding or knowing what I'm doing. Still, I constantly struggle with coworkers merging feature branches from 100 commits ago in to new feature branches and brute force resolving conflicts across half a dozen files in one commit without any context. I see it all because I have visibility in to the history and branch relationships but I still get shrugs and eye rolls when I bring it up. I don't necessarily want to dictate nitpicky git usage but I have a hard time accepting when people just to refuse how rebasing and cherrypicking work when they're both core basic features of a tool we all use every day. Proper Git use is one of those hills I'll die on, though so I don't intend to shut up about it any time soon :) 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.

dr-detroit 6y ago
NOBODY on my team learned ANYTHING about git. They stopped using it on new projects its like everyone considers their (shabby) work proprietary. Thank you for coming to my TED talk: life is suffering
forrestthewoods 6y ago
> 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.
- JadeNB 6y ago
  > 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.)
- gkoberger 6y ago
  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.
  - Supermancho 6y ago
    > 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.
zwieback 6y ago
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.
- phailhaus 6y ago
  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.
  - zwieback 6y ago
    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.
- redisman 6y ago
  It's really just using the old generic version control commands everyones used to.
f154hfds 6y ago
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.
kgwgk 6y ago
> about every developer uses git but most learn add, commit, branch, and merge and then just stop learning. What are branch and merge? /j
bluedino 6y ago
Git has over-complicated source control for the majority of developers. Things were much simpler with svn.
- tehbeard 6y ago
  > 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/ http://www-cs-students.stanford.edu/~blynn/gitmagic/> to go from <https://xkcd.com/1597/ https://xkcd.com/1597/> to the friend mentioned in the alt text. SVN still feels like I'm pulling teeth all these years later.
- kevin_thibedeau 6y ago
  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.
  - chipotle_coyote 6y ago
    IIRC, merging in SVN is... basically something you never wanted to do. :)
- MereInterest 6y ago
  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.
breck 6y ago
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.
- codyb 6y ago
  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.
  - turminal 6y ago
    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.
    - breck 6y ago
      Yes, good clarification. I probably write 10x (maybe 100x? more?) more throwaway regexes than regexes I commit.
  - trulyme 6y ago
    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.
    - breck 6y ago
      You can write correct ad hoc regex parsers for many subsets of HTML depending upon your needs.
- chipotle_coyote 6y ago
Vinnl 6y ago
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/ https://agripongit.vincenttunru.com/)
- bombcar 6y ago
  This looks nice but scrolling on Safari on Big Sur is causing weird artifacts. maybe if I scroll really slow
  - Vinnl 6y ago
    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...
mschuster91 6y ago
> 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.
- zo1 6y ago
  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.
- deleted 6y ago
  [deleted]
phendrenad2 6y ago
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.
secondcoming 6y ago
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)
- Sn0wCoder 6y ago
  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,
- kazinator 6y ago
  > help poor software development practices Says someone who's "never looked at our git graph".
  - secondcoming 6y ago
    Entertain me then, why do you need to look at it?
Solvitieg 6y ago
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.
- Espressosaurus 6y ago
  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.
  - wruza 6y ago
    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?
    - Espressosaurus 6y ago
      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: 4 | 3 | 2 | 1 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.
greggman3 6y ago
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.
- outworlder 6y ago
  > 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).
  - iudqnolq 6y ago
    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.
9dev 6y ago
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.
outworlder 6y ago
> 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).
- trulyme 6y ago
  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?
  - iudqnolq 6y ago
    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.
  - jfengel 6y ago
    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.
    - trulyme 6y ago
      Thank you (and the sibling) for the explanation, sounds useful!
chriswarbo 6y ago
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).
- bentcorner 6y ago
  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.
- iudqnolq 6y ago
  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.
ravenstine 6y ago
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.
- Izkata 6y ago
  > 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.
fshbbdssbbgdd 6y ago
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?
gregmac 6y ago
> 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.
- trulyme 6y ago
  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.
  - gregmac 6y ago
    > 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.
Stratoscope 6y ago
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.
- kevincox 6y ago
  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.
- bmn__ 6y ago
  > 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 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.
wruza 6y ago
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.
robaato 6y ago
How do you track which cherry picks have been done?
leokennis 6y ago
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.
hnjst 6y ago
> 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/ https://learngitbranching.js.org/

dr-detroit 6y ago

NOBODY on my team learned ANYTHING about git. They stopped using it on new projects its like everyone considers their (shabby) work proprietary. Thank you for coming to my TED talk: life is suffering

forrestthewoods 6y ago

> 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.

JadeNB 6y ago
> 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.)
gkoberger 6y ago
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.
- Supermancho 6y ago
  > 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.

zwieback 6y ago

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.

phailhaus 6y ago
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.
- zwieback 6y ago
  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.
redisman 6y ago
It's really just using the old generic version control commands everyones used to.

f154hfds 6y ago

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.

kgwgk 6y ago

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

bluedino 6y ago

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

tehbeard 6y ago
> 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/ http://www-cs-students.stanford.edu/~blynn/gitmagic/> to go from <https://xkcd.com/1597/ https://xkcd.com/1597/> to the friend mentioned in the alt text. SVN still feels like I'm pulling teeth all these years later.
kevin_thibedeau 6y ago
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.
- chipotle_coyote 6y ago
  IIRC, merging in SVN is... basically something you never wanted to do. :)
MereInterest 6y ago
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.

breck 6y ago

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.

codyb 6y ago
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.
- turminal 6y ago
  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.
  - breck 6y ago
    Yes, good clarification. I probably write 10x (maybe 100x? more?) more throwaway regexes than regexes I commit.
- trulyme 6y ago
  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.
  - breck 6y ago
    You can write correct ad hoc regex parsers for many subsets of HTML depending upon your needs.
chipotle_coyote 6y ago

Vinnl 6y ago

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/ https://agripongit.vincenttunru.com/)

bombcar 6y ago
This looks nice but scrolling on Safari on Big Sur is causing weird artifacts. maybe if I scroll really slow
- Vinnl 6y ago
  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...

mschuster91 6y ago

> 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.

zo1 6y ago
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.
deleted 6y ago
[deleted]

phendrenad2 6y ago

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.

secondcoming 6y ago

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)

Sn0wCoder 6y ago
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,
kazinator 6y ago
> help poor software development practices Says someone who's "never looked at our git graph".
- secondcoming 6y ago
  Entertain me then, why do you need to look at it?

Solvitieg 6y ago

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.

Espressosaurus 6y ago
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.
- wruza 6y ago
  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?
  - Espressosaurus 6y ago
    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: 4 | 3 | 2 | 1 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.

greggman3 6y ago

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.

outworlder 6y ago
> 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).
- iudqnolq 6y ago
  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.

9dev 6y ago

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.

outworlder 6y ago

> 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).

trulyme 6y ago
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?
- iudqnolq 6y ago
  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.
- jfengel 6y ago
  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.
  - trulyme 6y ago
    Thank you (and the sibling) for the explanation, sounds useful!

chriswarbo 6y ago

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).

bentcorner 6y ago
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.
iudqnolq 6y ago
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.

ravenstine 6y ago

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.

Izkata 6y ago
> 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.

fshbbdssbbgdd 6y ago

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?

gregmac 6y ago

> 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.

trulyme 6y ago
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.
- gregmac 6y ago
  > 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.

Stratoscope 6y ago

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.

kevincox 6y ago
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.
bmn__ 6y ago
> 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 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.

wruza 6y ago

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.

robaato 6y ago

How do you track which cherry picks have been done?

leokennis 6y ago

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.

hnjst 6y ago

> 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/ https://learngitbranching.js.org/