You should have the following components:

1. Business objects, which model and express one particular "thing" in your app:

   class Link { ... }
   class User { ... }
   

   These don't "do" anything, they're just there to formalise your data structures. These objects have getter and setter methods to get and set individual attributes, which are also validated there:

   public function setUrl($url) {
       if (!/* validate the URL here*/) {
           throw new InvalidArgumentException("$url is not a valid URL");
       }
       $this->url = $url;
   }
   

   Minimum required data is part of the constructor. This ensures your data integrity application-wide. It allows you to assert that when you have an instance of Link, the data expressed by it is minimum valid data for a link.

2. A database link. Only the bare necessary thing to connect to a database, nothing more, nothing less. A raw PDO or mysqli object will do just fine.

3. A data-object mapper, which takes a database link and knows how to store business objects in the database and how to retrieve them:

   class LinkStorage {
   
       protected $db;
   
       public function __construct(PDO $db) {
           $this->db = $db;
       }
   
   }
   

   This class has all the various methods of how to retrieve things from your database:

   public function getById($id) {
       $stmt = $this->db->prepare('SELECT ... FROM ... WHERE id = :id');
       $stmt->execute(compact('id'));
   
       if (!$data = $stmt->fetch()) {
           throw new RuntimeException("Record with id $id does not exist");
       }
   
       return new Link($data['url']);
   }
   

   You can have all sorts of different queries encapsulated this way, e.g.:

   /**
    * Returns all links by a particular user.
    * @param User $user
    * @return Link[]
    */
   public function getAllFromUser(User $user) {
       ...
   }
   

The usage is then simple:

$db          = new PDO(...);
$linkStorage = new LinkStorage($db);
$userStorage = new UserStorage($db);

$user  = $userStorage->getById($id);
$links = $linkStorage->getAllFromUser($user);

This kind of code would then be encapsulated in a service class, which holds all the possible "actions" you can do in your app. registerUser(array $data), getLinksOfUser($id), newLinkFromPostData(array $data) etc.

What I've just described is basically the model portion of an MVC-style application. The other two parts would be controllers which call the service methods, and views which output data retrieved from service methods. This approach keeps responsibilities separate and isolated and allows you to put higher-level logic and functionality together like building blocks. Business objects are the lowest building block, their structure needs to be solid and well defined for the rest to work. Data-object mappers just concern themselves with putting those objects into the database and getting them back out again. Services then put all this together in various complex ways and make things happen.

You shouldn't have any cyclic dependencies with this, as responsibilities are well separated. Your individual dependencies may still be somewhat complex. If it becomes too cumbersome to instantiate classes, you'll want to look into Factories:

$factory = new Factory;
$userStorage = $factory->newUserStorage();

All the complexity of instantiation is encapsulated in this factory. One step further are dependency injection containers, who you can configure in, for example, an XML file to specify which class depends on what, and then the DI container will take care of it for you.

In a lot of scenarios, procedural programming is just fine. Using OO for the sake of using it is useless, especially if you're just going to end up with POD objects (plain-old-data).

The power of OO comes mainly from inheritance and polymorphism. If you use classes, but never use either of those two concepts, you probably don't need to be using a class in the first place.

One of the nicest places IMO that OO shines in, is allowing you to get rid of switch-on-type code. Consider:

function drive($the_car){

    switch($the_car){

      case 'ferrari':
          $all_cars->run_ferrari_code();
          break;

      case 'mazerati':
          $all_cars->run_mazerati_code();
          break;

      case 'bentley':
          $all_cars->run_bentley_code();
          break;
    }
}

with its OO alternative:

function drive($the_car){

    $the_car->drive();
}

Polymorphism will allow the proper type of "driving" to happen, based on runtime information.

Notes on polymorphism:

The second example here has some premisses: That is that all car classes will either extend an abstract class or implement an interface.

Both allow you to force extending or implementing classes to define a specific function, such as drive(). This is very powerful as it allows you to drive() all cars without having to know which one you're driving; that is because they're extending an abstract class containing the drive() method or implementing an interface forcing the drive() method to be defined.

So as long as you make sure that all your specific cars either extend the abstract class car or implement an interface such as canBeDriven (both of which must declare the drive() method) you can just call the drive() method on an object which you know is a car (but not what type of car) without fear of it not being defined, as PHP will throw fatal errors at you until you define those methods in your specific car classes.

You'll probably want to write your source code to use a #defined constant version string. You can then pass that in through your build with a -DMY_VERSION=... option. That'll let you embed a default value in the code, too, wrapped in an #ifndef, just in case!

#ifndef MY_VERSION
#define MY_VERSION 0.0.1-alpha
#endif

print_version() {
    printf("my product: %sn", MY_VERSION);
}

A nice way to handle this on the build process side to make an intermediate build product which is simply a makefile snippet like MY_VERSION = "...". This again adds redundancy by letting you distribute the project with the version file already created, so that the build doesn't have to depend on the presence of the SCM.

You can then create the version string however you like, for example:

echo -n 'MY_VERSION = "' > VERSION_FILE
git describe >> VERSION_FILE
echo "Compiled on $(date)" >> VERSION_FILE
...
echo '"' >> VERSION_FILE

Then in your primary makefile, include that snippet, and add -DMY_VERSION='"$(MY_VERSION)"' to the build flags for the appropriate object.

A slight variation: make your generated file purely the version string, then pull that value into the appropriate variable in the makefile.

If you need help with specific git commands to get the desired output, feel free to comment. git describe is a great one, though, meant for exactly this kind of thing. The default output is the closest tag ancestor of the current commit, hyphen, number of commits since the tag, hyphen, and abbreviated commit hash.