It’s not uncommon to encounter requirements that involve multiple people collaborating on a common branch, but you’ll always see weird Git operations like merge (🤏), fallback, and push (black question.jpg).

Therefore, I would like to share with you my method, which is relatively clean and can ensure that future generations use silky, friendly to those who pursue smooth Git nodes, and can be assured to eat it.

  1. Every time your code is committed and before you change it again, remember firstgit pull
  2. Local code changes to submit, 🚶 old trilogy:
    1. git add .
    2. git commit -m 'feat: xxx'
    3. git push
  3. If there is no conflict above, then I write this article in vain 🙄️
  4. Is there a conflict? I told you there was. Here comes the essence:
    1. git logGet the current commit ID that you just committed
    2. git reset --hard HEAD^(Hard means to force a rollback, HEAD followed by ^ or ~ means to rollback a version, i.e. a commit.)
    3. git pullThe latest code on the pull line (this is a successful pull if there is no rollback of the common branch on the line that causes the node to change, otherwise the pull might conflict)
      1. If there is a conflict, executegit reset --hard <commit id>orGit reset - hard HEAD ~ < n >(n stands for any number, you can also use HEAD^^^^^, a few ^ to indicate a few steps back)
      2. To performgit pull
      3. If the conflict persists, go back to step I until there is no conflict
    4. git cherry-pick <commit id>This can be used if the COMMIT ID is lostgit reflogAnd then find the missing ID hash based on the commit message)
      1. If there is a conflict, modify it before performing the commit trilogy:
        1. git add .
        2. git commit -m 'feat: xxx'
        3. git push
      2. If there is no conflict, execute it directlygit push

Hope to you can some help (did not help close my PI matter 😳)