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.
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.
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.
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.
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.
Yeah. It’s got no abstraction between the UI and the implementation. You just want to manage code versions, but to use Git, you need to learn how to manage history graphs.
It was conceived for experts so the new user experience is shit and the UI is not intuitive. But it has become such a widespread standard that it is very hard to completely overhaul the UI.
Even for experts the user experience is shit. Too much has to be done manually when the default should be automatic, like fetching before pull, recursing when working with repos that use submodules, allowing mismatched casing on case insensitive filesystems, etc.
Yes you couldn’t change something so widely used. Look what happened with python 3.
Fortunately there’s already a tradition among Git users of building a UI on top of the git UI. My project is just a slightly better version of those. It lays a simple sensible interface on top of the chaotic Git interface.
TBH compared to the old versioning system people used to use like SVN and Mercurial. Git is a godsend. Just taking your time in learning and not using a GUI client works wonders in learning how it works. Especially when all the GUI clients are basically a collection of commands being executed so if you fuck things up on CLI you know what happened vs using GUI.
Add comment