Your hint says that the "HTTPS private key has been forgotten in Git." This could mean several things, but I suspect it means that the private key was added and deleted from Git history, which in turn means you can get it back.

Trawling Git

Quick peek

If the Git history is short, git log --stat and the pager might be enough. Run the command below, Ctrl+D until you find the right commit, and git show it.

git log --all --stat --oneline

In an assignment like this with mocked up Git history, that's probably all you need. If not, you can take a closer look:

Deeper dive

Filtering for files

Since your ps aux output says --key=/root//key.pem, try hunting for it. This path filter will check all for .pem files in all tracked folders:

git log --all --stat -- ':**/*.pem'

Filtering for text changes

If you have some text in mind to look for in a delta, there are two ways to do so. For you, search text might be -----BEGIN or PRIVATE KEY.

This first command runs faster, but disregards file renames or matched instances that are added and removed from the same file. The optimization mostly ignores refactors, but might miss what you're looking for under rare, unexpected circumstances.

git log --all --stat -i --pickaxe-regex -S'private key'

This next command takes two passes through the history, making it slower than the previous one, but it checks for the text in every commit.

git log --all --stat -i -G'private key'

Filtering for commit message

It's unlikely to help with your assignment, but you can also search commit messages. Sensitive data is usually added along with other files in innocuous-sounding commits. But sometimes you get lucky and the commit that removes the sensitive data says what it's doing.

git log --all --stat -i --grep='key|secret|sensitive|private|credential|password'

Lesson

If you or anyone on your team puts secret data into Git, you can't just git rm it away. Its content stays there in the history forever. You need to use a tool like git filter-repo or git filter-branch to get rid of it, and everyone with a clone of the repo who has fetched it since the secret was introduced needs to fix theirs, too. This might mean throwing their repo away and cloning a fresh copy.

There are several ways to manage sensitive data. Whichever one you choose, you want to make it hard for a contributor to do the wrong thing.