14 ms·

So many people have a hard time with git. I have yet to meet someone who understands git and uses it proficiently. What I tell every new programmer joining my

So many people have a hard time with git. I have yet to meet someone who understands git and uses it proficiently. What I tell every new programmer joining my team is to read chapter 10 (Git Internals) section 10.2 and 10.3 of the amazing online git book[0][1][2]. I can not insist enough on how important it is to understand the fundamental design of git, and it is really not complicated. This is what made me understand git and changed it from a hard tool to use, to this amazing productivity software that I love. The kicker for me was to realize that in git (mostly) everything is a reference to a commit id. What's a branch? It's a human readable string, made for humans, by humans, that ultimately simply references a commit id. What is a new branch? It's just a new human readable string pointing to a specific commit in your history. [0] https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po... [1] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects [2] https://git-scm.com/book/en/v2/Git-Internals-Git-References https://git-scm.com/book/en/v2/Git-Internals-Git-References

zwischenzug 9y ago
Learning git has given me many a-ha moments. Years ago it was even worse, with unstable porcelain and only the man pages for company. What made it all work for me was conducting courses in it, so I had to make the concepts vivid for people that weren't that interested in the theory. That forced me to reduce it to simple examples, which really worked.
JoshTriplett 9y ago
> I can not insist enough on how important it is to understand the fundamental design of git, and it is really not complicated. I absolutely agree. Everyone I know who has expert-level knowledge of git, and can do arbitrary things with it or solve arbitrary problems with it, thinks along the lines of "I want to get from this repository state to that repository state, what commands will get me there?".
deleted 9y ago
[deleted]
CodeMage 9y ago
I believe people have a hard time with Git because it's simply not user friendly. Once you've grokked a handful of essential concepts, Git becomes easy to use proficiently, but both the user interface and documentation are so user-hostile that most people never get to that point. A few examples: - `git reset` command can perform wildly different actions depending on its options - `git revert` does not do what most users would hope it does - if you actually need to revert your working tree changes, you might need to use `git checkout` Naturally, people get confused and reach for the docs, which are filled with even more newbie-hostile terms like 'tree-ish', 'hunks' and 'refspec'. As a result, people tend to see Git as this scary, incomprehensible hairball.
- tenken 9y ago
  I would argue git is not novice friendly. It's original intended audience was not lay people learning how to program. It was seasoned kernel developers working on the Linux source tree. It (made) assumption(s) it's userbase were experts in their domain. > Naturally, people get confused and reach for the docs, which are filled with even more newbie-hostile terms like 'tree-ish', 'hunks' and 'refspec'. Yup, these are everyday terms for an expert in computer science and algorithm and software design. If I were a student in medical school I'd expect the books I'm learning from to use the expert terminology of my domain of study when describing the body and functions and not laymans terms such as -- "the hip bone is connected to the Red-Squishy-Thing .... ELI5 me plz" ... I agree git is complex, and can be scary. But building software is a complicated process rife with engineering pitfalls! If one is unable to properly use the Lego building blocks, then stay away :D I do believe when used properly, a productive Git workflow using Branches and sane commit messages can help to give Visibility to your project development life-cycle and help to make an issue or task on a project understandable in scope and difficulty by segmenting ones development work into comprehensible mergable pieces (branches) within the project.
  - sneak 9y ago
    I know a lot of CS experts who go weeks without saying any of “hunks”, “refspec”, or “tree-ish”. You are making excuses for needless, opaque jargon.
nlawalker 9y ago
A lot of people simply don't understand why source control isn't a problem solved 100% by tooling in a way that requires little to no interaction at all. To them, hearing that they need to read a chapter about the internals of a source control system before working on a project is like hearing they need to understand the details of how a transmission works before they go and drive an automatic - it's inane detail about a workflow they shouldn't even have to deal with because technology has solved the problem, or should have by now. I was on a team that was forced to transition from TFS to git. Among those who weren't excited about it, the majority of the questions, challenges and issues weren't even as far down the road as how to use git, they were mostly along the lines of "why do we have to do all this other stuff now? Today I go to this screen, click this button, my work is now safe and other people can see it." History is linear, full stop, and conflicts are handled by essentially forcing a rebase on commit. Some admin does branching and merging and emails us if there are weird conflicts, we don't worry about that. Why make it more complicated? These folks didn't need git tutorials, they needed to be convinced that curation and management of source history was one of their job responsibilities, which was tough because it really wasn't previously, at least not in any meaningful way.
- vidanay 9y ago
  Git is the poster child for "leaky abstraction"
  - klodolph 9y ago
    I don't think leaky abstraction correctly describes the problem here, because the leaky thing (the fact that history is not linear, and multiple people edit the same files, and that everything is distributed) is not actually an abstraction. In my mind, Git forces you to deal with the fact that history is inherently nonlinear, and then you can choose to create a linear history by the way you use Git. Git's main abstraction is the fact that everything is a content-addressable blob. This "leaks" but it's not a major contributor to the problems people have using Git, at least from what I've seen.
    - 9y ago
mstade 9y ago
> The kicker for me was to realize that in git (mostly) everything is a reference to a commit id. Same here, and in fact this is almost verbatim how a friend and colleague explained it to me when I was first introduced to git some seven years ago. Once I got a grasp of that, it was almost like walking out of a dense fog. I learned to be very proficient – comfortable even – with git very quickly thanks in no small part to his mentorship. One of the first things he showed me after I royally screwed up a couple of weeks into the new job, was how to use the reflog. This is also when he explained the importance of the commit IDs to me, much like how you did above. I won't say I magically knew how to do anything in git from then on, but it certainly made understanding things a whole lot easier.
RobertRoberts 9y ago
I suffered using SVN for years, when I switched to GIT it was like pulling my head out of a plastic bag and breathing fresh air. It was unbelievably rejuvenating. Maybe if you are already skilled with one kind of version control system, GIT is easier to understand. But if you are starting from scratch with GIT, it's more difficult that way? (I am not sure, I only have one experience to lean on)
- webster23 9y ago
  For a newbie I think SVN is definitively easier to learn at first. But then you have to live with the limitations. Git is the better choice in the end, especially if there are more than a few people working on the same codebase.
ythn 9y ago
I would say a "tag" is a better example of a human-readable pointer to a commit. Branches are similar, but automatically "grow" to always point to the tip of the branch.
- kqr 9y ago
  Tags are in general more immutable -- you would't see a remote tracking tag, for example!
  - sigjuice 9y ago
    How are tags immutable? They can be deleted and added again to point at a different commit id.
    - sounds 9y ago
      Tags can be added (created). Tags can be deleted (permanently destroyed, though of course with the distributed nature of git, remote tags must then be handled in a separate step). But those are not intrinsic properties of the tag itself. Those are properties of the repo that holds the tag. The tag itself is immutable: It is a human readable name pointing to a commit id. And, to distinguish it from a branch, it can't be updated after it is created.
      - sigjuice 9y ago
        Setting aside the distributed nature of git, if I delete a tag and add it again to point at a different commit id, how can the tag be considered immutable? If I step away from my desk and come back and look at a commit id, I know it is exactly the same thing as before. I can’t say the same thing about a tag.
        gouggoug 9y ago
        The tag is immutable because you had to first delete it, then recreate it, to change its value. Technically the tag might have the same label (say v0.0.1), but it still is a new tag, that so happens to be labeled the same as your old immutable tag.
gt_ 9y ago
I think the problem is the arcane interface and documentations. The verbiage in the documentation is unnecessarily difficult if not a computer science major. I agree The Git Book is by far the best way I have found to learn it but the commands remain . I imagine they are some kind of balance between what operations are useful day-to-day and what is possible in respect to the program design but they fail so often because they have almost no consideration for interface design. I just wrote a script for determining which files are ignored by .gitignore in a repository and the solution I arrived at is nothing short of painful to think about. It is ugly, anything but intuitive and impossible to build a test for. What is the excuse for this?
- w0rd-driven 9y ago
  I'd be interested in that technique, he said, completely understanding the masochistic request. I use git based deployments in a fair number of scenarios (where the .git directory is not web accessible). Git status is the perfect mechanism for detecting code changes, the primary of which being intrusion or developers working on production directly which should never happen. Being able to detect the breadth of all the .gitignore files over the entire directory structure doesn't sound like a fun exercise but it would be a nice addition to be able to report on what ignored files exist. It's possible there's a command for this but I feel like you're confirming my assumption that such a thing doesn't exist.
- fwip 9y ago
  Really? It seems like find * -type f | join -v 1 - <(git ls-files) gets me maybe 90% of the way there.
- jcranmer 9y ago
  Well, to give some perspective, the hg command to do what you want is hg status -i. There are equivalent options to the hg status command to list only added, deleted, modified, deleted on disk but still tracked, files in the repo that are neither ignored nor tracked, and files that match the current checked-out commit. Admittedly, git status shows more information, but then again, hg usually doesn't need you to know about what you current state is to predict what will happen when you run a command.
mtkd 9y ago
If you grew up with Unix commands it makes sense (mostly), if you grew up with Photoshop it's really not very friendly. Stackoverflow top item on how to redo a commit (one of most common things a new user may need to do): $ git commit -m "Something terribly misguided" $ git reset HEAD~ << edit files as necessary >> $ git add ... $ git commit -c ORIG_HEAD I run a ton of aliases - some of them functions - just to do basics. I really like git - but it is a very steep learning curve for many.
- kccqzy 9y ago
  Isn’t `git commit --amend` enough? No need to reset and commit again.
  - dralley 9y ago
    Maybe if you only need to add something, but not if you included something you didn't want to in the commit, but you still want to leave the change there.
  - SiVal 9y ago
    Sometimes it's easier to undo & redo. That's the reset approach. (Reset, your mistake goes away, do it over again but right, then commit.) Sometimes it's easier to just make another change. That's the amend approach. (Keep what you've got, which was almost right, make another change--add, delete, or edit--so it's right, and re-commit as if you'd made that additional change from the start.)
- orev 9y ago
  I grew up with Linux and have used cvs, svn, git, and mercurial, not doing complex stuff, just basic. Out of all of them git is the most inconsistent and difficult to learn, both at the command level and in trying to deal with the docs and community around it. Everyone seems to think everyone else is a mathematician and every doc or message has this air of “if you don’t intrinsically understand DAGs then you’re just not worthy to use this tool”.
- IshKebab 9y ago
  > If you grew up with Unix commands it makes sense (mostly) > I run a ton of aliases ... just to do basics. So... it doesn't make sense then.
zombieprocesses 9y ago
I do agree that reading the documentation is helpful. But nothing beats using it. If people have a test machine or a VM to download/install git and create toy projects to learn the basics of git, that would be far more effective. Try branching, merging, diffing, committing, etc to get a better feel of how the source control system works. If you have background in subversion or other source control ( hell even experience in source safe might help ), then it would help you get caught up much faster. Also, there are tons of youtube videos on git if you learn better via video. But at the end of the day, if you don't use it, you aren't going to understand git.
- kqr 9y ago
  Easier said than done. My last team said they had used git a lot. Some were even very experienced. What they referred to was what I could most accurately describe with "Treating the GitHub website as a Dropbox except it forces you to confirm conflicting files on upload." I wish I could find the right words to convey what a nightmare that was. They ignored directory structure, straight up just committed any merge conflicts to the default branch, no sense in what happened in which commit, etc. Frequently overwrote each other's work, since their most reliable merge strategy was deleting the file entirely and then reuploading their own copy. By doing so, they created an endless series of conflicts where they alternatingly uploaded each of their copies -- both locally having a cohesive version, but anyone pulling from them got one or the other, depending on who uploaded last. They usually "fixed" this by hunting down the git conflict markers in the code and deleting just those, leaving two nearly indistinguishable copies of the conflicting hunk. Frequently the only difference was whitespace. If you tell a person lile that to "just use git more!" they would, best case, not know where to start. Worst case, they'd keep doing that.
deleted 9y ago
[deleted]
wokwokwok 9y ago
> The kicker for me was to realize that in git (mostly) everything is a reference to a commit id. sigh~ I think this is the actual problem with git. The idea that there is a fundamental abstraction that no one ever told you about git that will let you derive and understand its behavior from first principles is just wrong. What you need to understand (and all you really need to understand) about git is how to make it behave in a predictable manner, for your particular use case. Everything else is to support that, not vice versa.
InclinedPlane 9y ago
Git is ... alright, but it doesn't deserve quite as much praise as it gets. I have well over a decade of experience using source control at a fairly high level, and I have experience with a wide variety of source control systems. Git is currently more or less the best thing that's out there in a lot of ways, but it still has a whole shit-ton of shortcomings. Even when you use git according to the finest shade grown, hand picked, organic best practices available you are still going to routinely run into situations where dealing with git is just a straight up pain in the ass for no good reason. Every source control system has its weaknesses but in some ways git's are even more annoying because so much of the rest of it is engineered so well. It's like opening up the trunk on a maserati and finding a compartment that's lined with splintery unfinished recycled pallet wood and held together by chewing gum, it makes you wonder why it's there and why having some piece that is such a comparatively low quality continues to be tolerated year after year. Again, overall I think git is pretty great, but the persistent lack of effort toward improving git's core weaknesses is incredibly frustrating.

zwischenzug 9y ago

Learning git has given me many a-ha moments. Years ago it was even worse, with unstable porcelain and only the man pages for company. What made it all work for me was conducting courses in it, so I had to make the concepts vivid for people that weren't that interested in the theory. That forced me to reduce it to simple examples, which really worked.

JoshTriplett 9y ago

> I can not insist enough on how important it is to understand the fundamental design of git, and it is really not complicated. I absolutely agree. Everyone I know who has expert-level knowledge of git, and can do arbitrary things with it or solve arbitrary problems with it, thinks along the lines of "I want to get from this repository state to that repository state, what commands will get me there?".

deleted 9y ago

[deleted]

CodeMage 9y ago

I believe people have a hard time with Git because it's simply not user friendly. Once you've grokked a handful of essential concepts, Git becomes easy to use proficiently, but both the user interface and documentation are so user-hostile that most people never get to that point. A few examples: - `git reset` command can perform wildly different actions depending on its options - `git revert` does not do what most users would hope it does - if you actually need to revert your working tree changes, you might need to use `git checkout` Naturally, people get confused and reach for the docs, which are filled with even more newbie-hostile terms like 'tree-ish', 'hunks' and 'refspec'. As a result, people tend to see Git as this scary, incomprehensible hairball.

tenken 9y ago
I would argue git is not novice friendly. It's original intended audience was not lay people learning how to program. It was seasoned kernel developers working on the Linux source tree. It (made) assumption(s) it's userbase were experts in their domain. > Naturally, people get confused and reach for the docs, which are filled with even more newbie-hostile terms like 'tree-ish', 'hunks' and 'refspec'. Yup, these are everyday terms for an expert in computer science and algorithm and software design. If I were a student in medical school I'd expect the books I'm learning from to use the expert terminology of my domain of study when describing the body and functions and not laymans terms such as -- "the hip bone is connected to the Red-Squishy-Thing .... ELI5 me plz" ... I agree git is complex, and can be scary. But building software is a complicated process rife with engineering pitfalls! If one is unable to properly use the Lego building blocks, then stay away :D I do believe when used properly, a productive Git workflow using Branches and sane commit messages can help to give Visibility to your project development life-cycle and help to make an issue or task on a project understandable in scope and difficulty by segmenting ones development work into comprehensible mergable pieces (branches) within the project.
- sneak 9y ago
  I know a lot of CS experts who go weeks without saying any of “hunks”, “refspec”, or “tree-ish”. You are making excuses for needless, opaque jargon.

nlawalker 9y ago

A lot of people simply don't understand why source control isn't a problem solved 100% by tooling in a way that requires little to no interaction at all. To them, hearing that they need to read a chapter about the internals of a source control system before working on a project is like hearing they need to understand the details of how a transmission works before they go and drive an automatic - it's inane detail about a workflow they shouldn't even have to deal with because technology has solved the problem, or should have by now. I was on a team that was forced to transition from TFS to git. Among those who weren't excited about it, the majority of the questions, challenges and issues weren't even as far down the road as how to use git, they were mostly along the lines of "why do we have to do all this other stuff now? Today I go to this screen, click this button, my work is now safe and other people can see it." History is linear, full stop, and conflicts are handled by essentially forcing a rebase on commit. Some admin does branching and merging and emails us if there are weird conflicts, we don't worry about that. Why make it more complicated? These folks didn't need git tutorials, they needed to be convinced that curation and management of source history was one of their job responsibilities, which was tough because it really wasn't previously, at least not in any meaningful way.

vidanay 9y ago
Git is the poster child for "leaky abstraction"
- klodolph 9y ago
  I don't think leaky abstraction correctly describes the problem here, because the leaky thing (the fact that history is not linear, and multiple people edit the same files, and that everything is distributed) is not actually an abstraction. In my mind, Git forces you to deal with the fact that history is inherently nonlinear, and then you can choose to create a linear history by the way you use Git. Git's main abstraction is the fact that everything is a content-addressable blob. This "leaks" but it's not a major contributor to the problems people have using Git, at least from what I've seen.
  - 9y ago

mstade 9y ago

> The kicker for me was to realize that in git (mostly) everything is a reference to a commit id. Same here, and in fact this is almost verbatim how a friend and colleague explained it to me when I was first introduced to git some seven years ago. Once I got a grasp of that, it was almost like walking out of a dense fog. I learned to be very proficient – comfortable even – with git very quickly thanks in no small part to his mentorship. One of the first things he showed me after I royally screwed up a couple of weeks into the new job, was how to use the reflog. This is also when he explained the importance of the commit IDs to me, much like how you did above. I won't say I magically knew how to do anything in git from then on, but it certainly made understanding things a whole lot easier.

RobertRoberts 9y ago

I suffered using SVN for years, when I switched to GIT it was like pulling my head out of a plastic bag and breathing fresh air. It was unbelievably rejuvenating. Maybe if you are already skilled with one kind of version control system, GIT is easier to understand. But if you are starting from scratch with GIT, it's more difficult that way? (I am not sure, I only have one experience to lean on)

webster23 9y ago
For a newbie I think SVN is definitively easier to learn at first. But then you have to live with the limitations. Git is the better choice in the end, especially if there are more than a few people working on the same codebase.

ythn 9y ago

I would say a "tag" is a better example of a human-readable pointer to a commit. Branches are similar, but automatically "grow" to always point to the tip of the branch.

kqr 9y ago
Tags are in general more immutable -- you would't see a remote tracking tag, for example!
- sigjuice 9y ago
  How are tags immutable? They can be deleted and added again to point at a different commit id.
  - sounds 9y ago
    Tags can be added (created). Tags can be deleted (permanently destroyed, though of course with the distributed nature of git, remote tags must then be handled in a separate step). But those are not intrinsic properties of the tag itself. Those are properties of the repo that holds the tag. The tag itself is immutable: It is a human readable name pointing to a commit id. And, to distinguish it from a branch, it can't be updated after it is created.
    - sigjuice 9y ago
      Setting aside the distributed nature of git, if I delete a tag and add it again to point at a different commit id, how can the tag be considered immutable? If I step away from my desk and come back and look at a commit id, I know it is exactly the same thing as before. I can’t say the same thing about a tag.
      - gouggoug 9y ago
        The tag is immutable because you had to first delete it, then recreate it, to change its value. Technically the tag might have the same label (say v0.0.1), but it still is a new tag, that so happens to be labeled the same as your old immutable tag.

gt_ 9y ago

I think the problem is the arcane interface and documentations. The verbiage in the documentation is unnecessarily difficult if not a computer science major. I agree The Git Book is by far the best way I have found to learn it but the commands remain . I imagine they are some kind of balance between what operations are useful day-to-day and what is possible in respect to the program design but they fail so often because they have almost no consideration for interface design. I just wrote a script for determining which files are ignored by .gitignore in a repository and the solution I arrived at is nothing short of painful to think about. It is ugly, anything but intuitive and impossible to build a test for. What is the excuse for this?

w0rd-driven 9y ago
I'd be interested in that technique, he said, completely understanding the masochistic request. I use git based deployments in a fair number of scenarios (where the .git directory is not web accessible). Git status is the perfect mechanism for detecting code changes, the primary of which being intrusion or developers working on production directly which should never happen. Being able to detect the breadth of all the .gitignore files over the entire directory structure doesn't sound like a fun exercise but it would be a nice addition to be able to report on what ignored files exist. It's possible there's a command for this but I feel like you're confirming my assumption that such a thing doesn't exist.
fwip 9y ago
Really? It seems like find * -type f | join -v 1 - <(git ls-files) gets me maybe 90% of the way there.
jcranmer 9y ago
Well, to give some perspective, the hg command to do what you want is hg status -i. There are equivalent options to the hg status command to list only added, deleted, modified, deleted on disk but still tracked, files in the repo that are neither ignored nor tracked, and files that match the current checked-out commit. Admittedly, git status shows more information, but then again, hg usually doesn't need you to know about what you current state is to predict what will happen when you run a command.

mtkd 9y ago

If you grew up with Unix commands it makes sense (mostly), if you grew up with Photoshop it's really not very friendly. Stackoverflow top item on how to redo a commit (one of most common things a new user may need to do): $ git commit -m "Something terribly misguided" $ git reset HEAD~ << edit files as necessary >> $ git add ... $ git commit -c ORIG_HEAD I run a ton of aliases - some of them functions - just to do basics. I really like git - but it is a very steep learning curve for many.

kccqzy 9y ago
Isn’t `git commit --amend` enough? No need to reset and commit again.
- dralley 9y ago
  Maybe if you only need to add something, but not if you included something you didn't want to in the commit, but you still want to leave the change there.
- SiVal 9y ago
  Sometimes it's easier to undo & redo. That's the reset approach. (Reset, your mistake goes away, do it over again but right, then commit.) Sometimes it's easier to just make another change. That's the amend approach. (Keep what you've got, which was almost right, make another change--add, delete, or edit--so it's right, and re-commit as if you'd made that additional change from the start.)
orev 9y ago
I grew up with Linux and have used cvs, svn, git, and mercurial, not doing complex stuff, just basic. Out of all of them git is the most inconsistent and difficult to learn, both at the command level and in trying to deal with the docs and community around it. Everyone seems to think everyone else is a mathematician and every doc or message has this air of “if you don’t intrinsically understand DAGs then you’re just not worthy to use this tool”.
IshKebab 9y ago
> If you grew up with Unix commands it makes sense (mostly) > I run a ton of aliases ... just to do basics. So... it doesn't make sense then.

zombieprocesses 9y ago

I do agree that reading the documentation is helpful. But nothing beats using it. If people have a test machine or a VM to download/install git and create toy projects to learn the basics of git, that would be far more effective. Try branching, merging, diffing, committing, etc to get a better feel of how the source control system works. If you have background in subversion or other source control ( hell even experience in source safe might help ), then it would help you get caught up much faster. Also, there are tons of youtube videos on git if you learn better via video. But at the end of the day, if you don't use it, you aren't going to understand git.

kqr 9y ago
Easier said than done. My last team said they had used git a lot. Some were even very experienced. What they referred to was what I could most accurately describe with "Treating the GitHub website as a Dropbox except it forces you to confirm conflicting files on upload." I wish I could find the right words to convey what a nightmare that was. They ignored directory structure, straight up just committed any merge conflicts to the default branch, no sense in what happened in which commit, etc. Frequently overwrote each other's work, since their most reliable merge strategy was deleting the file entirely and then reuploading their own copy. By doing so, they created an endless series of conflicts where they alternatingly uploaded each of their copies -- both locally having a cohesive version, but anyone pulling from them got one or the other, depending on who uploaded last. They usually "fixed" this by hunting down the git conflict markers in the code and deleting just those, leaving two nearly indistinguishable copies of the conflicting hunk. Frequently the only difference was whitespace. If you tell a person lile that to "just use git more!" they would, best case, not know where to start. Worst case, they'd keep doing that.

deleted 9y ago

[deleted]

wokwokwok 9y ago

> The kicker for me was to realize that in git (mostly) everything is a reference to a commit id. sigh~ I think this is the actual problem with git. The idea that there is a fundamental abstraction that no one ever told you about git that will let you derive and understand its behavior from first principles is just wrong. What you need to understand (and all you really need to understand) about git is how to make it behave in a predictable manner, for your particular use case. Everything else is to support that, not vice versa.

InclinedPlane 9y ago

Git is ... alright, but it doesn't deserve quite as much praise as it gets. I have well over a decade of experience using source control at a fairly high level, and I have experience with a wide variety of source control systems. Git is currently more or less the best thing that's out there in a lot of ways, but it still has a whole shit-ton of shortcomings. Even when you use git according to the finest shade grown, hand picked, organic best practices available you are still going to routinely run into situations where dealing with git is just a straight up pain in the ass for no good reason. Every source control system has its weaknesses but in some ways git's are even more annoying because so much of the rest of it is engineered so well. It's like opening up the trunk on a maserati and finding a compartment that's lined with splintery unfinished recycled pallet wood and held together by chewing gum, it makes you wonder why it's there and why having some piece that is such a comparatively low quality continues to be tolerated year after year. Again, overall I think git is pretty great, but the persistent lack of effort toward improving git's core weaknesses is incredibly frustrating.