this post was submitted on 04 Apr 2026
14 points (79.2% liked)

Learn Programming

2153 readers
1 users here now

Posting Etiquette

  1. Ask the main part of your question in the title. This should be concise but informative.

  2. Provide everything up front. Don't make people fish for more details in the comments. Provide background information and examples.

  3. Be present for follow up questions. Don't ask for help and run away. Stick around to answer questions and provide more details.

  4. Ask about the problem you're trying to solve. Don't focus too much on debugging your exact solution, as you may be going down the wrong path. Include as much information as you can about what you ultimately are trying to achieve. See more on this here: https://xyproblem.info/

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 2 years ago
MODERATORS
 

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".

you are viewing a single comment's thread
view the rest of the comments
[–] eah@programming.dev 2 points 1 week ago

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.