This is a tough question as it cover a lot. Not to mention the unknowns:

• Complexity of your org
• Distribution/roles of your team/members
• What tools you have available (paid, specific tools you have to use, etc)

I'll try to cover some good starting points, but you'd have to ask more specific questions as you undertake the journey and hit roadblocks. Or, if it's more open-ended/discussion-based (which isn't best-served on this site) - you can look to leverage trailhead groups or other sites (reddit, sfxd discord).

In short, I would particularly recommend going through the Salesforce Developer Tooling Learning Map. It contains most of the below and a lot more resources for planning, coding, testing, and deploying in the whole process.

---

Several important notes:

1. Get others invested in doing this with you instead of a one-person show.
2. It's tools, technology, process, and people that make the DevOps process work.
3. You can't change their process overnight
4. This change needs to be planned for - ex. plan for "learning", slower initially
5. You need to time to learn. As you mentioned, you're green to this and it sounds like you may be the only one familiar with how well it looks when effort is put to get behind this.

Some learnings/trailhead everyone should start with

• Learn Why Version Control Is Important for Team-Based Development
• Development Models
• Getting Started with Salesforce DX series

SalesforceDX is the Salesforce Developer Experience (DX) which covers the environment/tools at your disposal to develop on the platform. Some highlights/benefits include:

• The ability to apply best practices to software development. Source code and metadata exist outside of the org and provide more agility to develop Salesforce apps in a team environment. Instead of the org, your version control system is the source of truth.
• A powerful command-line interface (CLI) removes the complexity of working with your Salesforce org for development, continuous integration, and delivery.
• Flexible and configurable scratch orgs that you build for development and automated environments. This new type of org makes it easier to build your apps and packages.

In general, the setup can be as simple as:

• Salesforce CLI
• VS Code
• Your Source Control provider (ex. Github, Bitbucket, etc).
• Enable Dev Hub Features in your Org (necessary if using Scratch Orgs)

As you noted, they only have one dev org. See if you can spin up others, do they have a full sandbox, partial sandbox, etc. In the end, as you noted, source control (your repository) should be your source of truth as your primary goal.

---

Most of what I recommend above is to start learning so you and your team can decide what path to take forward. There's more drastic changes (package-based development with scratch orgs) and there's smaller, but still value-driven, changes you can make (source control being source of truth). Others may not want to put in the work, but source control/git/devops is an opportunity to improve your experience as well as learn new, valuable skills as orgs get more and more complex.

I'd say your first steps, simply put, are:

1. Take time to learn the tools and new concepts
2. Decide on the change you want to make
3. Start making progress towards that goal.
4. Set milestones