When making pull requests, there are a number of things you may forget to do and hence lead into problems when trying to merge, and others. Therefore, ensure that you do the following
1: Got a ticket? Ensure the pull request you are about to create, is for an existing JIRA ticket. If the ticket does not exist, create it. Since we use JIRA tickets to audit and inform release notes, we shouldn't be handling pull requests in GitHub without any documentation in JIRA (except for very trivial changes like fixing typographical errors). When you create a ticket, it starts in a "Needs Assessment", or "In Backlog/Ready for Analysis" state. Do not work on it until when someone assesses it and eventually makes it "Ready for Work" or "Waiting for Dev". This will help you avoid wasting time working on what is not necessary. Also the ticket assessor may even give you some pointers regarding how to get started with this particular ticket, which files to change, and more. We call this ticket curation. When ready to start working on the ticket, click the "Claim Issue" or "Claim for Development" button to assign it to yourself, and hence prevent others from duplicating your efforts by working on the same ticket. When a ticket has a status of "Ready for Work" or "Waiting for Dev", it means that no one is working on it and hence available for you to claim it. In order to claim a ticket, you need to first log in JIRA.
...
9: Squash! The best practice is to commit at the level of an idea (feature/fix). While you may have made 10+ commits while you worked, before you submit a pull request, make yourself look even smarter as if you knew how to do it all at once by "squashing" your changes into one that addresses the ticket. For example: git rebase -i HEAD~3, where the "3" in HEAD~3 is refers to the number of prior commits you want to squash and then git commit.[ref]
Large features may be done across a handful of commits, but most bug fixes and small features can be squashed into a single commit, making the commit history easier to follow.
Consider squashing when creating a pull request; don't worry about squashing subsequent commits performed in response to the reviewer(s) comments. Ultimately, the person merging the pull request will perform a "squash on merge" via GitHub to make the final result appear as a single, clean commit.
...
15: Abandoning a ticket. If you decide not to do any more work on a ticket, either because of lack of time, or any other reason, remember to unassign yourself from it such that it becomes available to someone else to take it over from where you left. If during the course of working on it, you discover something that may be useful to whoever takes it up, share that as comments on the ticket. If you had attempted to open any pull request, remember to also close it with a comment stating why.
16: Travis CI GitHub Actions build failures. After After creating a pull request, check to ensure that Travis CI GitHub Actions builds successfully. If you end up with something like this: "continuous-integration/travis-ci/pr — The Travis CI build failed" then the build fails, click the "Details" link next to it for details regarding the failure. This mostly happens if you forget to run "mvn clean install" to ensure that all tests pass before committing.
...