Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
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.
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.
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
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.
The greatest trick the devil ever pulled was convincing the world that he didn't exist
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?
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.
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.
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.
Comment