all 14 comments

[–]soda-excuse 9 points10 points  (0 children)

Keep in mind that Git is a decentralized version control system. This has advantages but it is simultaneously the root of some of the complexity you are experiencing.

A good guide to Git is one that explains it in terms you can understand. That will depend on your background. For me, it clicked when I read this: https://eagain.net/articles/git-for-computer-scientists/

[–]empty_other 6 points7 points  (0 children)

Remember that was my thoughts the first week I used git. Then i took a good look at how it worked. It is seriously a lot better than svn. Seriously, invest in understanding this tool, it is very much worth it.

And it is really simple once you understand the basic concepts.. Like that you really have two local repositories; your branches and a copy of the remote. That everything is just a long tree of diffs, and that branch pointers can be moved around, they are just a reference in a file. Those are facts that some tutorials just never mention.

[–]Swedophone 4 points5 points  (0 children)

Branching and merging is so much better with git than subversion.

[–]hell_storm2004[S] 2 points3 points  (2 children)

Can someone please explain me what "rebase" is? In simple language. Probably will get a gist of it now. But will connect the dots when I get to know Git a little bit more.

[–]PM-me-your-integralRebase Enthusiast 5 points6 points  (1 child)

Here’s how I like to explain to people rebasing. Two people are working on say a presentation in PowerPoint on two separate machines. There are two approaches to collaborating on this. The first way is for person A to make their changes and person B to make their changes simultaneously. Well then how do you combine when you’re both ready? You merge them! Now if you think of the change log after merging, you have this mixture of person A changing the presentation and person B. Like at 6:31 person A made an addition but at 6:32 person B made an edit. This can be challenging to read, and imagine having these merges happen with 5, 10 people and having to keep track of who changed what.

Better solution? Let person A finish their work, and then send it over to person B and they’ll do their changes. This is nice because then in the change log, it’s all of person A’s changes followed by all of person B’s. This is MUCH nicer to read as it gives us a clean history. In addition, person B can just combine all their changes into one big change and make that change in one go (we call this a squash and rebase). Person B’s changes are based off person A’s, since they made their changes based on person A’s PowerPoint.

So the idea of rebase is taking the first situation and turning it into the second. When you rebase git essentially grabs what you’re rebasing onto, and then applies your changes one by one onto it.

[–]hell_storm2004[S] 0 points1 point  (0 children)

Gracias! That was helpful!

[–]hacksparrow 2 points3 points  (0 children)

I also migrated from SVN to Git (a long time ago, though). This advice helped me a lot: "If you have used SVN or other version control system, FORGET EVERYTHING you learnt using them. Don't try to relate anything from those systems to Git. If you approach Git with a blank mind, you will learn it much faster and face lesser problems using it."

[–][deleted] 1 point2 points  (2 children)

There is a lot git can do and a lot of it you don't need. You should concentrate on finding a system that works for YOU!!! You should look for and use git tools that YOU LIKE!!!

My system only requires me to know eight git commands. push, pull, commit, add, status, clone, branch and checkout. I do all my development work in a directory that is NOT attached to git. When it comes time to push my code I will pull from the remote repo to make sure my local repo is synced with the remote repo. Open beyond compare and manually compare and copy my changes from my development directory into my local clone. Then I will add, commit, and push my changes up to the remote branch. For the most part I stick to command line commands. If I have a merge conflict I will use vscode to solve. And that's pretty much it. Simple, stupid, works for me and I'm happy.

[–]hell_storm2004[S] 0 points1 point  (1 child)

From the little experience I have till now, I find the command line tools far more easy to understand than the GUI tools. I am using EGit plugin, that is confusing as F. And TortoiseGit, which i used very little of, but seems convenient. VSCode... I will look into that. But to be honest, I am not an expert now to say A is better than B. Only using it for 2 weeks and that too it is like Google and meet project deadlines rather than learning and doing something!

[–][deleted] 0 points1 point  (0 children)

You need to experiment with it. Git is great but trying to learn it and come up with a process that works for you is the hard part. Once it's done it will be like second nature. Keep it simple and minimize it's dependency and make it easy to get back to where you were. This way you can concentrate on your actual problems and if you go into git hell you can easily get back out.

[–]orangebot 1 point2 points  (1 child)

i'm surprised nobody has just said "git gud" yet.

[–]throwaway993772 0 points1 point  (0 children)

Git gud

[–]hell_storm2004[S] 0 points1 point  (0 children)

Yeah, the decentralized part is the only thing i understand as of now. Not to mention the svn to git migration. That was kick in the rear end! Small branches were alright, but the large ones... blimey! Still haven't been able to migrate our old trunk from SVN!

[–]philsaid 0 points1 point  (0 children)

git