It’s the thing you use to create a local copy of the main code base, and then merge your changes back in.

OP hasn’t done anything, and there’s 7 conflicts between his code and main. Presumably because someone else merged their changes in the time between when OP pulled his local copy and tried to push his (non-existent) changes.

is what people who don’t know vim and rsync have to use to mimic 1% of our power

deleted by creator

It’s what americans from a rural area say when they want you to go away.

A very complicated way to do

My project
My project (1)
My project WORKING
My project (2)
My project (2) (1)

git gud. HA, GOTTEM

If it was dead simple you wouldn’t need to learn 10 new concepts and google commands regularly even after using it for a couple of years. You probably forgot how you struggled at first. I have taught it multiple times and I see how beginners struggle.

It’s not THAT complicated but I wouldn’t call it dead simple. When you understand how git works internally yeah it’s pretty simple but people usually start with the idea that it’s a tool to put your code on a server to synchronize with other people and only later learn that you have both a local and a remote (or multiple remote) tree and how the tree really works.

I think the problem is most git 101 tutorials teach it wrong, IMO the best git tutorial is this: https://wildlyinaccurate.com/a-hackers-guide-to-git/

Unfortunately it’s pretty dense so it’s gonna scare off a lot of newbies.

It’s definitely not simple to use but I agree that the conceptual model it represents is straightforward. I think a lot of the problems people have with git come from not understanding the underlying data structure before learning how to manipulate it.

I would actually say it’s VERY complicated but in daily work you probably need like 5 commands and those aren’t hard at all.

Its not dead simple but its also not extremely complex.

I’m currently working with some interns and there’s just concepts they were never exposed to. Without decent mentoring, git can be difficult because a lot of the workflow does come with experience.

That being said everyone needs to stop acting like its an impossible task to properly do source control. There is some truth that if you don’t care enough to do your source control, you don’t care enough to write decent code. Its not a moral failing, just take some pride in your craft.

Show the newbies how to care and they’ll care enough to want to do it right. Measure twice, cut once and all that.

Solving merge conflicts or rebasing is not simple

Go, Team Rebase!

Also, a way to never have to work again!

One key thing that can help you wrap your head around rebasing is that branches get switched while you’re doing it; so, say you’re on branch feature and do git rebase master, for any merge conflict, whatever’s marked “current” will be on master and what’s “incoming” is from feature.

There’s also git rerere that should in theory remember a resolution you do between two branches and reuse it every time after the first; I’ve rarely used it in practice; it would happen for long lived branches that don’t get merged.

this is easily fixed by copy pasting the files into a new directory and never opening git again out of fear

Oh, you haven’t seen my lack of skill then.

deleted by creator

git out

Wow this looks great. Amend an old commit dealing with a rebase? Sign me up!

LazyGit may actually be black magic from Satan to tempt programmers into sin. And to that I say: ‘where is a goat I can sacrifice to my dark lord?’

I’d still probably prefer the usual CLI for setup, commits, pushes etc. but this looks like a godsend for any branching/rebasing operations!

sccs

1973

rcs

1982

git

2005

How long are your years?

Subversion is as good as it can get with centralized version control system.

CVS is only one step up above FTP file server for all your code.

deleted by creator