Afterwards you should be able to sign emails send to “RIPE Database” <firstname.lastname@example.org> with your NemID certificate and the updates gets approved if your maintainer has authorization over the object you try to create/modify/delete.
Being new to git. You will inadvertently struggle.
Having opened a pull request (PR), leaving the PR hanging for a while, picking it up Y time later, with several changes have happened in the upstream branch. You will often find yourself in need of using git rebase upstream/master ((https://git-scm.com/docs/git-rebase)).
After having rebased recent commits upon the upstream/master branch. You might want to squash your commits together, to create a cleaner pull request, and to avoid (un)intentionally blotting the git-history with miscellaneous commits, imagine:
pick = use commit
reword = use commit, but edit the commit message
edit = use commit, but stop for amending
squash = use commit, but meld into previous commit
fixup = like "squash", but discard this commit's log message
break = stop here (continue rebase later with 'git rebase --continue')
drop = remove commit
If in need of deciding which commit to squash together, and were to edit the commit message. Using git rebase --interactive (commit-hash, remote-name/branch-name, or branch-name) is the lifeline.
Remember, the commit hash will change when using git rebase action. Force pushing to the remote branch to replace its contents is necessary. git push remote-name local-branch-name:remote-branch-name --force (e.g. git push origin master-squashed-commits:master --force).
But this approach is the recommended way in regards to using git pull-requests. Any existing pull-requests against a branch you have on your fork of the upstream repository. Will automatically use the latest available information in your fork’s branch.