There is GIT (the system itself) and there is the CLI.
While GIT itself is very elegant and clean, the CLI is the exact opposite. In my experience people who struggle with GIT mostly struggle with its CLI and do a lot better with a graphical interface, given they understand the concept of distributed VCS.
Git is too hard
61–70 of 821 posts
Re: Git is too hard
#62I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…
Agreed - I started to use version control back with SCCS somewhen in the early nineties, and RCS, CVS, Subversion, ClearCase, some Microsoft horror with a name I can't recall, and a few others. My conclusion is exactly the same as yours: " Git is the simplest version control system I've ever used. " And it also improved my overview over what happens and has happened in the past - I can jump back in for stuff I haven'…
The version control system your subconscious mind recoils in horror from is the dreaded Visual SourceSafe, one of the worst-named product ever.
Re: Git is too hard
#63As with many things, the solution is complex because the problem is complex. Managing code history in a distributed manner, handling conflicts and allowing cooperative coding is not an easy problem to fix.
Having said this, Git doesn't make it easy by the terminology and concepts that are used. And also the inconcise UI (you use git reset for a lot of very different actions, some harmless, some very destructive) doesn't make it easy for a newcomer. Who will often resort to just remember oneliners or look them up from a manual without knowing what they actually do.
What really helped me in understanding Git was to understand the mechanics of the database on an abstract level. Commits and how branches/tags relate to them. If you understand that commits (not branches) are the tree and the branches just post-it's you put on the commits and can rearrange as you please everything becomes much more malleable. Once you discover commits are hardly ever deleted/lost, but just the post-it's are moved (which makes the commits invisible), things become easily recoverable and fixable. Also not using code, but cats[1] also seems to greatly reduced the complexity of learning Git for me. Visual tools like Ungit[2], Tig[3], or plain Git log[4] help to see the commit tree and attached branches and gives an idea of how the data is manipulated.
There is also the Gitless[0] project which tries to redefine the UI of Git, without changing the data format itself. It offers a different look at the same repository and more clear and dedicated commands/concept to perform certain tasks. And since it just uses Git itself underneath you can seamlessly switch between it and Git without issues.
[1] https://girliemac.com/blog/2017/12/26/git-purr/
[2] https://github.com/FredrikNoren/ungit
[3] https://github.com/jonas/tig
[4] git log --oneline --decorate -50 --all --graph --remotes
Re: Git is too hard
#64Git's plumbing is simple and intuitive.
Git's UI has grown organically and is still not great for common tasks like undo, however they are working on it and it is slowly improving. For example, they've just added a restore command which should make it simpler to undo changes (git restore filename):
https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things
Things I'd also like to see improved:
Undoing things locally should be very simple and intuitive - perhaps restore will help.
Conflict resolution when changes happen on the same line, so that there are fewer clashes on rebase/merge.
Git log should be compact and pretty by default
Git push should push tags as well by default
Deleting tags etc on a remote has a really weird syntax - git push origin :tagname git push --delete origin tagname just feels really odd instead of using the tag command.
There should be a simple way to add all changes and commit - e.g. git add --all && git commit -m "Message" if that could be git commit "Message" that'd be great (probably not possible but at least a flag on commit would be nice). I have an alias set up for this. I like being able to add files separately to a list then commit too, but that is far rarer, most of the time I want to commit all changes.
A blessed workflow - perhaps this isn't possible but having one workflow would make it simpler to move between repos and simpler. Many projects seem to have settled on main=production with short-lived feature branches rebased off main and edit as necessary locally before sharing on main. This works well for us at my workplace.
git start - a guided tour command which steps a user through a typical workflow and shows them the commands they need (probably about 5 commands initially), and tells them the difference between local and shared commits (fine to change vs never try to change).
These are pretty minor gripes though most of which can just be fixed with some aliases for commands - I'm pretty happy with it and much prefer it to what came before.
Re: Git is too hard
#65Git is one of those technologies where it's super important to get a good grasp of how to internals work. Once you got that, it get easier to answer git questions for others or yourself, and to read the documentation or man pages, as you know what is happening. With how software devs use git, it's 100% worth it to read a good book on it.
What book(s) would you recommend?
I think https://learngitbranching.js.org/ shows the internals of git's graph model quite nicely.
Re: Git is too hard
#66I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…
I slightly disagree. I think git is simple, but the UX (the way the commands and flags are designed) is really bad so that's why it's perceived as hard.
It's the case with most UNIX CLI tools and if the author's complaints are true, do we then have to change all UNIX CLI tools? Maybe? The reality is we can't and probably don't need to.
Re: Git is too hard
#67I think it boils down to Git solving a complex problem in a very elegant way. Other version control systems try to simplify the problem, but the result tend to make some part of a dev team more unhappy than git does
Re: Git is too hard
#68Earlier quoted context omitted.
Yes, it works but not intuitive. I mean why use the checkout for the file reversion? And I think that's the problem of git: it's powerful and it works, but it's really not easy to get started.
There are numerous git svn cheat sheets ... this is literally one of the first things I learned. I’m kind of bewildered by this to be honest ... I don’t know how somebody with a technical qualification could have trouble with this ...
We shouldn't need a cheat sheet. We shouldn't need Linus's brain dump to be able to use a tool. The Git UI directly models the Git internal model and that's just bad design. It's a completely leaky abstraction.
I can use git all right but the fact that I need about 20 different commands to do my job, 95% of them with extra parameters and almost all of them with names that don't reflect what I want to do from a functional point of view is utterly dumb. Again, functional! not technical! The UI should reflect end user functionality, not internal technical details.
Re: Git is too hard
#69I find it a little confusing, especially when trying to do something a little unusual. For example, I had a git repo on a web host and wanted it moved to another host (they cloned it easily enough), but then I wanted to make the cloned repository "authoritative", but I after several hours of looking for an answer I finally gave up. I was able to clone the new repo to my local machine, but I couldn't push changes to t…
There is a technical difference between an local repo and a remote repo (bare repository) - although I think you can clone from a repo and make this "authoritative", what you usually do is (in your client, not the server)
- add a new remote
- push your tree to this new remote
- remove the old remote (optional)
And that's it.
You're further not supposed to make commits on a remote directly. Usually this fails hard, for a reason.
Re: Git is too hard
#70I would say that people only need to initially learn: checkout, add, commit, push and pull. Those operations cover most of a devs daily workflow (for most companies I've worked at at least). Anything else can be figured out/taught as needed, it's much easier to learn a new concept when you have a use case specific to you.
I know git internals. But I still struggle to have a correct mental model of developping features on branches that you then merge into a very distant branch.
It is ok when you create a branch from develop, code your feature and merge back to develop.
But then things get messy: you need to backport that feature to some release branches.
And all that is asynchronous (backport feature « n+1 » but not feature « n » nor « n-1 » from develop onto branch 1.0 LTS and branch 2.0-SNAPSHOP. ok done? Perfect, let’s ship that. Good feedback from users? Ok cool. Now do the same with « n-1 »)
you want to keep track of code movements between branches, so you use merge (not rebase or cherry-pick).
Pffffiou I honestly do not know how to handle that at scale with Git.