For Arists
Create branches based on the assets you are adding. Also, try not to touch any levels/scenes, only work on your own files and make sure you follow the pull request guidelines.
Feature Branches
Naming
Name feature branches with a dev_ prefix to make it clear that they are features. Otherwise, follow the naming conventions in the above pictures.
Pull Requests
After your feature is complete, make a pull request and then resolve it by yourself. They are just there to keep track of finished features. Preferably, leave the pull request open for a small period of time (1-2 days) so that others can take a look at it if need be, but use discretion, if it needs to be merged in right away then do so.
Continuous Integration/ Continuous Deployment (Long term goal)
Squash commits before publishing
Gitlab has a setting to automatically squash commits after a mergre request is approved, GitHub might have the same thing, but try to squash your commits before you publish your branch to keep things simple.
Squashing can also be dangerous if merge commits somehow get mixed up in them, because they can undo a lot of work if not all branches have the same history. Only squash your own work to prevent this.
Feature Ownership
The programmer that creates the feature is responsible for maintaining the feature, and is also responsible to answer any questions about the implementation.
Developer Folders for Unreal might be something worth trying out.