Today I did a git push --force, then I had to create a branch out of the old code, but other times I had to save the files I worked on, delete the local repository, git clone again, then reapply my fixes. I want to at least have a bookmark on how to fix things in the future.

Yes, I’ve heard about VSCode plugins, that supposed to help. But no, I don’t want to use a glorified webpage to do coding, regardless if it’s directly tied to Micro$lop, or some of the slop was removed by 3rd parties. I tried KATE once, I cannot go back to some sluggish webpage, which only argument for use at the moment is “but it has plugins”.

  • mikerenfro@piefed.worldEnglish
    0·
    1 month ago

    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.