GIT - is it me or is it just really horrible?

[_V_]

Git is great, sourcetree is not a great UI.

This is a better GUI for Git.

https://www.gitkraken.com/

[_V_]

If you are using Visual Studio Code as your code editor it has Git source control built in. Just add something like Git lens and you can see file history etc in the code editor directly.

https://marketplace.visualstudio.com...amodio.gitlens

[NickFitz]

Git is a complete pain, yet also excellent for the purposes it serves

One useful resource is Oh tulip, Git!?! (I had to link to the SFW version "Dang it, Git!?!" as the naughty words filter broke the URL) which explains how to get yourself out of numerous common situations. But they're all in terms of the command line.

If you crave a deeper understanding of how Git works, which is definitely helpful in figuring out what's going on, then the official Git book is the place to start.

I used to use SourceTree but haven't in a while, as I use JetBrains IDEs these days and they have their own UIs for dealing with Git. I still regularly cock things up, but I have a slightly better idea now of how to recover.

[d000hg]

Git is great, sourcetree is not a great UI.

This is a better GUI for Git.

https://www.gitkraken.com/

I use that one too (in fact with the same client I use ST). Not sure I see much difference.
For normal dev work: create a branch, work in it, merge it back in (maybe with a PR) both work smoothly. Beyond that level of use I get nervous

[LondonManc]

imho Git is a lot harder if you've historically been happily using Microsoft's source control tools (TFS/Azure Dev Ops). The concept of locking an item by checking it out, working on it then checking it back in against the task/story that you were updating it for is all very logical.

Coming to git after years of that is difficult, having been through it. You almost have to do what Yoda suggests and unlearn what you have learned.

The main issue I have with git is that you can check something back in over the top of something else and lose someone else's changes if comms aren't perfect.

[_V_]

It sounds to me like people are using Git wrong. I've used it solidly for about 5 years, never lost a commit or overwritten anyone else's work. You are using something like Git flow yes? Branch and merge? Nothing is ever lost, you only have to deal with conflicts.

If you are getting lots of conflicts it means either you are taking way too long to complete your changes, or there are hotspots in the code structure that need to be refactored.

I can't understand how anyone can find Git complicated for 99.99% of the everyday tasks?

What are you people from the Visual Source Safe era?

[The Spartan]

I used to use GUI's with Git and found it really confusing, so I eventually switch to using the command line. Ever since then I've had no issues, however the built in version control UI's in VS Code (free) and IntelliJ (Paid for) are great.

[Fraidycat]

Git takes a few months to get used to.

But once you do, it is really powerful, we have multiple projects, each will multiple development branches and multiple release version branches.

And git makes life really easy for managing all of the branches and releases.

I use the command line myself, also stack overflow answers to command git problems are mostly command line answers..

[Dark Black]

It sounds to me like people are using Git wrong. I've used it solidly for about 5 years, never lost a commit or overwritten anyone else's work. You are using something like Git flow yes? Branch and merge? Nothing is ever lost, you only have to deal with conflicts.

If you are getting lots of conflicts it means either you are taking way too long to complete your changes, or there are hotspots in the code structure that need to be refactored.

I can't understand how anyone can find Git complicated for 99.99% of the everyday tasks?

What are you people from the Visual Source Safe era?

Do you think these two statements may be related?

Experience with any task will generally make that task seem easy/straightforward.

imho Git is a lot harder if you've historically been happily using Microsoft's source control tools (TFS/Azure Dev Ops). The concept of locking an item by checking it out, working on it then checking it back in against the task/story that you were updating it for is all very logical.

Coming to git after years of that is difficult, having been through it. You almost have to do what Yoda suggests and unlearn what you have learned.

The main issue I have with git is that you can check something back in over the top of something else and lose someone else's changes if comms aren't perfect.

And this I suspect is why I'm having issues. It's not just a MS source control tool background either, most (if not all) of the non-Git repositories I've used have worked pretty much the same way.

[_V_]

It's called a distributed source control system. This isn't your grandads source control.

https://www.oshyn.com/blog/2012/06/v...vs-centralized

You guys been living under a rock?

On the other side, a Distributed VCS, like Git, is considerably faster and easier to work with when it comes to creating and merging branches and tags. Also, they allow for flexible workflows, tailored to one’s project and team needs.