I guess nowadays you can summarize the whole book into "never push to main branch directly (unless it's a small project)", "have CI/CD with PRs which you code review", "branches cause distance between developers", "branches should be as short-lived as possible". That's about it, from the things that will be useful for a today's software engineer.
Yet, it gives very interesting history on CI/CD, VCS systems, and how PRs and the now-common "trunk based development" became a thing. If you're very much into those subjects, and want to master your knowledge on this, this book may be a quick useful read for you to catch up on this. That's why I still liked it, and not regret reading this.
Things I really enjoyed: Branches create distance between developers and we do not want that. Don’t break the build, always stay release ready. High quality code by promoting code reviews and pair programming.
A very clear and no-nonsense book highlighting single branch model of work, commonly known as GitHub Flow. This book abstracts it and covers a lot many aspects of the benefits, pitfalls and trade offs in the context of CI and CD.
A good 1 day read for architects, developers and EMs.
Must read. Le livre est très bien, bien que nous faisions déjà quelque chose de similaire dans la team, ce livre m'a permis de mettre la théorie sur la pratique et d'enforcer des règles qui ne l'étaient pas encore au sein de l'équipe. La delivery s'en porte bien.