git pull is dangerous, but not a security problem. The only danger is that it's difficult or inconvenient (but not impossible) to recover to the state prior to the pull, if it would be necessary.

Merge commits

The remote branch might have diverged from your own, in which case git will automatically try to resolve any conflicts with a merge commit. This might result in bad conflict resolutions (although that's rare).

This can be solved by running git pull --ff-only instead, which will only merge the origin changes if your local branch can be fast-forwarded (no merge commits).

If there are any local changes not in the remote branch, the pull will fail, and you'll be able to resolve the situation with a different method.

However, this solution doesn't solve the other problems of git-pull(1), so continue reading.

Predictability

git-pull(1) performs two operations:

• download the latest branch from the remote
• merge it to the local branch

But you can't predict what's in the remote branch. This means that your local branch will blindly jump to whatever commit the remote branch is in (assuming git pull --ff-only, and that your local branch has no changes).

You won't know where your branch was prior to the jump, unless you wrote the old commit hash somewhere. If after the pull you find out that you don't like the changes and want to go back to the old state, it will be hard to know where you were. (Imagine for example that the remote could have been hacked, and malicious contents could have been introduced in the branch.)

git-pull(1) has no way to mitigate this, since it's a problem inherent to the fact that git-pull(1) performs two operations.

The solution is to run two commands to perform those operations separately:

• git fetch origin
• git merge --ff-only origin/master

Between the fetch and the merge, you can print a graph of the log, to analyze what will be merged:

$ git fetch origin
$ git log --all --graph --oneline
$ git merge --ff-only origin/master  # or rebase, or whatever you need; you already know what you're merging.  :)

Printing the log graph in the terminal will also let you have all the commit hashes written, in case you make any mistakes and need to go back to the original state (git reset <old-master> --hard) and start again.

This approach allows you to review all of the remote commits before merging them into any local branch.

posted 2 months ago

CC BY-SA 4.0

2mo ago

alx‭

569 reputation 16 9 87 125