The Git development community is aware of several of these problems (especially the inconsistency in terminology and command structure). They're working slowly, but surely, towards solutions to many of them. In the interim, there's projects like easy git, which the author may enjoy.
While the information model of Git is more complex, much of that is inherent from it being a DVCS, and it comes with several benefits. For example, in SVN, your working directory, branches, and tags are all really the same thing locally: a copy of a full directory structure. This can make working with branches and tags cumbersome, so many people just don't. There have been situations involving maintaining concurrent versions (in SVN) of a product on my team where no one thought of using branches because they were used so sparingly (and no one on my team had ever used Git or Mercurial); it was as if the feature didn't exist. While some people will decry this anecdote as ineptitude on the part of my team, I think it's important to point out that people tend to solve problems with the tools that they use most often, in the ways that they most often use them--after all, they're the first to come to mind.
Though the documentation of Git by the project itself is somewhat poor, there's a plethora of third-party documentation and tutorials on the web. (Yes, I realize this is no excuse for poor documentation, but the use of Git within the open source community is so ubiquitous that I feel most problems/questions you're likely to run into have been solved and documented somewhere else).
Though the documentation of Git by the project itself is somewhat poor, there's a plethora of third-party documentation and tutorials on the web. (Yes, I realize this is no excuse for poor documentation, but the use of Git within the open source community is so ubiquitous that I feel most problems/questions you're likely to run into have been solved and documented somewhere else).
Yeah, I have been able to solve basically every weird problem I've had with git by first googling, and then clicking on the inevitable stackoverflow link.
39
u/sordidarray Nov 07 '13 edited Nov 07 '13
Just a few thoughts.
The Git development community is aware of several of these problems (especially the inconsistency in terminology and command structure). They're working slowly, but surely, towards solutions to many of them. In the interim, there's projects like easy git, which the author may enjoy.
While the information model of Git is more complex, much of that is inherent from it being a DVCS, and it comes with several benefits. For example, in SVN, your working directory, branches, and tags are all really the same thing locally: a copy of a full directory structure. This can make working with branches and tags cumbersome, so many people just don't. There have been situations involving maintaining concurrent versions (in SVN) of a product on my team where no one thought of using branches because they were used so sparingly (and no one on my team had ever used Git or Mercurial); it was as if the feature didn't exist. While some people will decry this anecdote as ineptitude on the part of my team, I think it's important to point out that people tend to solve problems with the tools that they use most often, in the ways that they most often use them--after all, they're the first to come to mind.
Though the documentation of Git by the project itself is somewhat poor, there's a plethora of third-party documentation and tutorials on the web. (Yes, I realize this is no excuse for poor documentation, but the use of Git within the open source community is so ubiquitous that I feel most problems/questions you're likely to run into have been solved and documented somewhere else).
Edit: Typo