How to get auto-merged git pull changes without conflicts? Is the more recent change the main one?

Question

git

I am using GIT to keep my personal knowledge base in sync. The knowledge base is a set of several thousand *.txt, *.html, *.xml files.
To sync I use the following "universal" command:

git add . ; git commit -a -m MyCommit ; git pull -s recursive -X theirs ; git push

However, sometimes when I edit the same place in a file from different computers, I get conflicts. And they need to be manually resolved. This is inconvenient, and besides, a wrapper was written over the knowledge base, which stops working if a conflict is marked in the root XML index file (the XML simply does not parse). You have to manually edit the file.
Since this is a personal knowledge base, and I can only be in one place at a time, the rule can be applied to such a base: the latest changes are the most important .
Question:What are the git pull options to get the latest changes so that conflicts are automatically resolved? In other words: how do you ensure that, in the event of a conflict, later (i.e. more recent) changes are simply applied?

Answer 1

What's the point on different machines to edit the same thing?
Normal pull workflow, made changes, committed, push. On another machine, pull, make changes, commit, push. Profit!

Answer 2

> Normal pull workflow, made changes, committed, push. On another machine, pull, make changes, commit, push. Profit!
This is if there is always internet. Often there is no way to commit due to the lack of a network, power is often cut off and you stomp home from work without committing. There are many different situations. Plus, on a mobile device, I forgot to pay for the Internet. You never know.

Answer 3

For Git, there is no concept of a "later commit", for it all commits made from the same ancestor are parallel.
In your generic team, you create a commit and then, during pull, ask to resolve conflicts automatically using the changes from the remote branch, that is, you resolve conflicts in favor of the changes you made earlier. Which, I think, is a little counter to the desire to use the most recent changes made.
Perhaps ours strategy is more suitable for you.
In this case, no merge is performed, the pointer is simply thrown to the last local commit. All deleted change history is ignored.