So you're going to git gud?

if u ever get a tricky merge conflict, just git push --force. this automatically works out the right code to keep (your own)

Highly recommend bookmarking https://ohshitgit.com, it'll steer you right 👍

1. git pull
2. git reset --hard HEAD
3. try not to cry
4. cry a lot

lemme rebase the main branch onto my branch.

two minutes later

1 merge conflict of 57 [abort] [continue]

Pro tip: If your code gets flogged by git, you can always get revenge with git reflog 😉

Learning git is very easy. For example, to do it on Debain, one simply needs to run, sudo apt install lazygit

Git is a great invention but it has a few design flaws. There are too many ways to confuse it or break it, using commands that look correct, or just forgetting something. I ended up writing simple wrapper script codebase to fix it. Since then no problems.

Literally.

This has been the best git tutorial I’ve come across so far. Nicely interactive and gamified. https://learngitbranching.js.org/

...not by choice, because if I don't I'll lose my job

Just rebase your life already

Great meme, and I'm sure op knows this, but for anyone else who is curious...

007 in theory means:

• 00: you have already committed your code to your local code base
• 7: When you try to merge your code with everyone else's there are 7 files that others have worked on since you last refreshed your local code base.

To resolve this, you need to go file by file and compare your changes with the changes on the remote code. You need to keep the changes others have made and incorporate your own.

You can use git diff file_name to see the differences.

If you have made small changes, it's easier to pull and force an overwrite of your local code and make changes again.

However multiple people working on the same files is usually a sign of organizational issues with management. Ie, typically you don't want multiple people working on the same files at the same time, to avoid stuff like this.

If you're not sure, ask someone that knows what they're doing before you follow any advice on Lemmy.

I prefer rebasing on destination branch before merging. When merging you get all the conflicts at the same time. When rebasing you can address conflicts from one commit at a time. Untangling multiple small knots is easier than one huge spaghetti. Also commit history will be much cleaner.

When we switched from svn, we had to figure out git with submodules.. that was fun

sccs, rcs, cvs... after that it's a blur of new systems every year or two

If you can't use git I don't see how you're gonna do with other things. It's dead simple.