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.
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.
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.
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.
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.
Using a tool like VSCode to perform the actual merges on individual files also helps because it shows what “yours” and “theirs” changes are from a user perspective, not a git perspective
It’s doable once you know what you’re doing. I can do it all via the cli, but I personally use gitkraken most of the time and it’s just so much easier and more ergonomic.
I also see a lot of the Devs who insist they know what they’re doing create horrible messes of their branches super easily via the commit tree. People should just use whatever works best for them to get the job done.
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.
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.
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.
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.
sublime merge is pretty great, but having a working familiarity with the underlying tool is invaluable when shit inevitably goes sideways while collaborating
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
midwest.social
Newest