Singleaxis tracking and backtracking, part 1
The tracking algorithm used in most commercial PV tracking systems is fairly sophisticated. It has to be able to know where the sun is and how to orient the array to best take advantage of the available sunlight. Let's figure out how they work!
At the basic level, the goal of tracking is to point the panels towards the sun as directly as possible. This maximizes module exposure to beam irradiance, which makes up the majority of incoming sunlight. Tracking can be implemented any number of ways. One of the more exotic methods involved black balloons filled with a volatile liquid. The balloons were placed under each side of the modules so that when the modules faced away from the sun, the exposed balloon heats up and expands, pushing the modules until the light is blocked. I'll leave the downsides to this approach as an exercise for the reader.
Another "empirical" approach is to detect solar position electronically and rotate appropriately with a motor. The internet is full of toy examples of this approach (for instance) because photodiodes are cheap and because this approach dynamically detects solar position, you don't have to go to any trouble aligning the tracker mount or worrying about what time of year it is or where in the world you are. However, relying on instrumentation to determine the optimal angle is a little risky  the angle calculation would get thrown off by stray reflections, small obstructions (grasshoppers!), snow accumulation, sensor drift...
The most common approach is to use a mathematical model to calculate solar position based on array location and time of day and calculate the optimal tracker position with a little trigonometry.
Solar Position
One of the most popular methods of determining the position of astronomical bodies is to use premade ephemeris tables (e.g. JPL Horizons 1). Another method (and the default in pvlibpython 2) is the NREL Solar Position Algorithm (SPA) 3. The SPA is fairly complex (the current pvlib implementation is over 1000 lines of code), but highly accurate, capable of calculating
solar zenith and azimuth angles in the period from the year 2000 to 6000, with uncertainties of \(\pm0.0003^\circ\)
So suffice to say it'll be fine for our purposes. Given a latitude, longitude, and datetime, we can calculate solar position to a much higher precision than any tracker could take advantage of. Technically the SPA also requires pressure, temperature, and atmospheric refraction but these have small effect and pvlib supplies suitable default values.
Tracker Geometry
Look at this excellent diagram:
Credit: Submerged and Floating Photovoltaic Systems: Modelling, Design and Case Studies. Marco RosaClot and Giuseppe Marco Tina, 2018.
Unfortunately it's for a southfacing system and we're talking about NS axis systems that rotate EW.
Using the labeling in that diagram, the SPA gives us solar zenith \(\theta_z\) and solar azimuth \(\gamma_s\). Because our trackers can only rotate in a single axis, we can collapse the NS axis without losing any necessary information.
Look at this crappy diagram:
This is looking along the NS tracker axis and \(x\) is along the EW axis. \(\phi\) is both the solar zenith angle adjusted for the NS collapse and the tracker angle that aligns the row as directly as possible towards the sun.
Once solar position is determined, calculating the tracker angle that minimizes angle of incidence is pretty straightforward:
Very easy!
It has all the properties you'd expect  facing straight east in the morning, rotates to flat at midday, and faces straight west in evening. This is the "basic" tracking pattern and is called truetracking.
References
 1

JPL HORIZONS emphemerides https://ssd.jpl.nasa.gov/?ephemerides
 2

pvlib.solarposition https://pvlibpython.readthedocs.io/en/stable/api.html#solarposition
 3

I. Reda and A. Andreas, Solar position algorithm for solar radiation applications. Solar Energy, vol. 76, no. 5, pp. 577589, 2004. https://midcdmz.nrel.gov/spa/