Honestly, just use a GUI. Graphical user interfaces were designed for a reason. I usually use SourceTree or the Git functionality built in to Visual Studio or VS Code.
It’s good to know how things work under-the-hood (e.g understand Git’s object model, some basic commands, etc) but don’t feel like you need to use the command-line for everything.
In my experience, using GUIs is how people fuck themselves, and then I have to unfuck them via the command line.
Git’s interface is bad, yes. It has a step learning curve, yes. But I truly think the only real way to overcome those obstacles is to learn how git works, learn all the nitty gritty details, not hide from them.
I use a GUI (GitKraken) to easily visualise the different branches I’m working on, the state of my local vs. the remote etc. I sometimes use the gui to resolve merge conflicts. 99 % of my gut usage is command line based.
GUI’s definitely have a space, but that space is specifically doing the thing the command line is bad at: Visualising stuff.
lazygit or tig are terminal interfaces for git. very nice, best of both worlds imo. every action shows the git command ran at the bottom, and its a lot easier to see at a glance the status, diff, log, etc.
My take is use a GUI for anything read-only/nondestructive (i.e. anything that won’t modify your local or remote state). It’s nice for example to compare the state of two branches.
For anything that does changes make sure you know what’s happening under the hood, otherwise you might shoot yourself in the foot. It’s convenient for example to do a commit and push in one go, but then you lose the ability to edit any changes (you’re forced to either do another commit, or change your local commit and force push).
In VSCode you can go to the Output pane and switch to Git - there you’ll see everything that gets done through Git’s CLI for whatever you do through the GUI (although it can be a bit noisy); same goes other GUI utils.
This is great, but I just want to say that the best way to use git is to simply stop doing so much in one branch. Branches should not last longer than a week, ideally
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.
If I get a big conflict and I know my change is trivial, I feel perfectly okay doing git fetch git reset --hard whatever and then reapplying my simple change as a new commit. Sort of a bootleg rebate.
First, I hard disagree with you. Overwriting my local version of code is a parachute - not an ideal landing, but better than merging by hand.
Also, my comment was not an attempt to teach everything about git, just to explain what is happening in simple terms, since git requires a lot of experience to understand what those messages mean.
Read… instructions? I love teaching people that git very often prints out what you should do next.
git: “to continue, resolve conflicts, add files, and run rebase —continue”
dev: …time to search stack overflow
All that said… just use lazygit. It does help to know CLI git first to put things in context, but if you do, no need to punish yourself every day by not using a UI.
midwest.social
Hot