https://github.com/k88hudson/git-flight-rules/blob/master/README.md

I always like the website https://ohshitgit.com/ for all kinds of common git issues.

Disclaimer: it's been a while since I've used git.

You'll be unable to push if the remote branch has diverged since you pulled because someone else has pushed changes different from your own.

One way to resolve this is to run git pull. If your commits have made changes to a file and the diverging commits have made changes to the same file, then you'll have a conflict and git will put your local repo into a special merge conflict state. Your working files involved in the conflict will be automatically changed to include the differing changes, delimited by <<<, ===, and >>> characters. You'll have the option to abort the pull or edit the files, git add them, and then git commit which completes the pull. You can then push.

git pull will do git fetch to update your copy of the remote branch, followed by a git merge. The documentation for resolving merge conflicts is contained in the git-merge man page: git help merge, particularly in the sections entitled "Pre-merge checks", "How conflicts are presented", and "How to resolve conflicts". Side note: the man page will open in the system pager, in which typing /conflict and the keys n and N will step through each occurrence of the word "conflict". Oh, you can even read it in glorious PDF.^[https://manpage.me/index.cgi?apropos=0&q=git-merge&sektion=0&manpath=Debian+8.1.0&arch=default&format=pdf]

Running git pull when you have uncommited files may be a different story entirely. Best to not do that. You can check whether your working files are clean with git status. It seems like the "proper" way to deal with this situation, if you must, is with git stash. That supposedly can be used to save your uncommited changes, cleanup your worktree to prepare it for a pull, and reapply the saved changes after.

I recommend sections in the free Pro Git book if your want something more pedagogical than the man pages.

The post was getting long enough already, but see the end of the conflicts section for several things you can do to reduce the likelihood of conflicts. Some are technical, others are more about communication and management.

The replies so far aren’t wrong, but there’s probably a more fundamental issue here.

Your risk of conflicts increases as you add more clones, add more working copies, add more collaborators. It usually decreases if folks regularly push their changes, regularly pull others’ changes, and get out of each others’ way by judiciously using branches and merging the branches back in when the work necessitating that branch is completed.

We use these materials to teach scientists and engineers about Git, and the specific section on resolving conflicts is here. We don’t cover branching since we only have a couple hours total.

The workflow we try to drill into the students starts out as:

1. Make changes.
2. Run git add and/or git rm to set what will be committed.
3. Run git commit to commit those changes.
4. Repeat from 1.

Nobody ever gets conflicts at this stage because there’s only one working copy and one repository per student. No remotes, no collaborators, no extra clones.

Then we bring in remotes. This changes the workflow to:

1. Make changes.
2. Add/rm.
3. Commit.
4. Push.
5. Repeat.

Still no conflicts as long as there’s only one working copy, one local repository, and one remote that’s basically a push-only copy of the local repo.

Then we add a collaborator and the workflow changes to:

1. Pull.
2. Make changes.
3. Add/rm.
4. Commit.
5. Push.
6. Repeat.

Still no conflicts as long as only one person at a time is working, and as long as each person does all the steps, including the pull.

The conflicts section starts with one or more collaborators omitting the pull step, making concurrent changes to the same part of a file, and pushing.

That’s all that’s required to cause a conflict, and it gets technically resolved by the later pusher editing the files to remove the conflict punctuation, making a new local commit with those changes, and pushing. Git itself doesn’t care if it’s the “correct” set of changes, only that the conflict punctuation is removed.

Check out the Atlassian docs for any git related topics or commands as they are usually easier to make sense of with example situations and explanations beyond describing just the feature or functionality.

Second this.

https://www.atlassian.com/git/tutorials/merging-vs-rebasing

You should also set it in your got config to pull.rebase true to avoid fast forwarding and other issues without being aware of how changes on main actually affect your branch changes and resolving them yourself so that your changes make actual sense when going into main.

Since no one is answering directly, here’s the steps to follow and you can go from here to find the specific commands. If you want to get back to a specific point in the history of the remote repo as a means to undo a mistake, and then continue from that point with any changes then usually you want to do this in a non-destructive way. ie. accept you screwed up and don’t cover it up.

There are many ways but this is the way that works.

• Keep a second copy of the local repo with the current state and changes you’ve made. If you screw up git commands this is your physical reset and save point for the repo history log and changes you made.
• Find the commit in git log you want to go back to and save that commit hash.
• Git checkout that commit in you local. You are now in the point at the past before it all went to shit.
• git diff the files that you want to apply changes with the ones in the copied repo and create a patch file. There are many ways to solve this, but this way you have a physical record of the changes, seperate from the git repo and you can do with them what you like. Include read and view them yourself.
• git checkout to main again on latest commit/head
• use git revert to utilise the built in undo convenience this provides by taking the state of the local repo to the commit hash in the past and committing changes to make this possible on top of the current state to make it the same but without erasing the history that you screwed up. All changes are additive even the ones to remove changes.
• now git push (without the force since you are not a jedi by any means and this is a humbling moment on this path to become one)
• now create a new branch for the changes you originally intended to make and pretend you haven’t wasted this time and are actually net positive because of the learning experience
• apply the patch files to the files you want to change and hope they apply, if not, manually resolve any merge conflicts by hand
• commit the changes to the local branch
• push the branch to remote
• do a pull request and summarise what all the changes are in the branch
• merge the changes into main branch and squash the commits
• realise that your original method is really no different as to the result, just now you have some more fancy ways to achieve it

You do realize that you don’t have to read a documentation from beginning to end, don’t you? But for that specific feature you need and don’t know how to use—RTFM!

As others have said, you need to at least learn the basics about git such as branches, remotes and merging. No plugin or tool will help you avoid that. When you feel very comfortable with the basics, I recommend learning how to rebase instead of merging for conflict resolution.

Perhaps these may help you:

https://learngitbranching.js.org/

https://gitmastery.me/

https://onlywei.github.io/explain-git-with-d3/

I want to learn about that specific issue rather than spending months with learning less often used features of a software. People generally don't master all the available functions of a software before touching said software. Maybe in the sixties-seventies, but not anymore. And there's also the issue of people forgetting stuff, which will happen when my main interaction with git is pull and push.

Is the official git documentation insufficient?

I'm writing my own cross-platform library, iota.

Do you want to use pipewire to play audio in your C program? This might help https://docs.pipewire.org/page_tutorial.html Although it's easier and practical to use cross-platform libraries such as SDL or PortAudio instead

Go's val, err := maybeDoThing() pattern isn't the same thing because it's not a discriminated union like Rust's Result or C++'s std::expected or the Typescript example in the article. Moreover, due to restrictions in Go's generics, it's impossible to implement what is imo the most attractive pattern enabled by the discriminated union Result types - monadic operations.

Thank you! Apparently, they did not mention Rust, too ^^"

Ditto for rust, although I didn’t read the article to know if they mentioned that one lol

This is quite interesting, since the article states absolutely nothing about Go language.
Since, it's the most common or even fairly standard technique in the language:

func Hello(name string) (string, error) {
    // If no name was given, return an error with a message.
    if name == "" {
        return "", errors.New("empty name")
    }
    // ...
}

Source: go.dev/doc/tutorial/handle-errors

Is it enough if I only use the header files?

You sure you actually looked? https://github.com/PipeWire/pipewire/blob/master/src%2Fpipewire%2Fpipewire.h

I can assure you, they are in the repository.

While true, as an old Vim user, I'm recommending finding some other modal-editor: too much cruft in Vim.

I hear Helix is modal.

( modal-editors help bash one against one's unconscious-mind's woodenness: forcing switching-of-levels, & if you read "The Design of Everyday Things", which Adam Savage also recommends people read, as he found it life-changing, then you'll read that NOT-switching-levels is a racial mental-defect: we just enforce-harder, instead of switching-levels, & break opportunity we're in!

So, modal-editing helps break that ignorance, giving us better ability to get out from the wrong-level into the right-for-the-context level, & therefore I absolutely recommend modal editors, for nearly-all.

However, vi & vim .. a bit too much cruft, in the crystallization.

Clean-slate optimization of what commands are in, what key-codes are for what, etc, ought produce a better tool. )

_ /\ _

I'm astonished that nobody has ever told me about this before.

I mean, it is right there in the welcome screen - where I, myself, foolishly ignored it for six years.

So now I also try to tell people about it. Haha.

It really is great.

Does anyone know of a package directory for these types of things? Something like octopi for apt.