It might be useful to present an introduction and basic user guide to GIT repository …..
It might be useful to present an introduction and basic user guide to GIT repository …..
Yayay, GIT wars 
.
Jon is right that branch strategy is important when working with production vs project code, with several parties working on both.
If one starts such an exercise without a strategy, it just gets out of hand.
You will have version control, but a complex release process with the risk of having to resolve merge conflicts (or overwrite fixes done in the production code -> regression) at the very end when you go live.
Doing this pure in GIT, without support of one of the platforms to manage the pull request cycles, is a rough ride.
It's hard enough with the support of those platforms.
I have experience with branch policies and pull request approaches in Azure DevOps and GitHub. Learning GitLab ...
The only difference is that I have the habit to never delete branches, also the dead ones. But as you say, this is an approach – very good in my opinion – that is based on a strategy. We adopt almost the same but it is the approach topic. Then branching, pull, joining, requests for merging, forking, and all the other possibilities and features, as the expression of the full potential of Git. I suppose you agree with this.
Years ago, were times when Nokia still was a top company, Symbian and Maemo was the top for mobile OS, Wt was version 3 or 2.xxx and in the group of Nokia developers, I was participating to some stuff in the dev team of what it was expected to be a very advanced, powerful and revolutionary SBC. In the meantime, as a Qt-ambassador, I participated mostly as a tester as a member of the opensource group (many people from Trolltech, some very respectable super-skilled guys from the Qt community, and other very experts Qt developers) in the creation of the porting of Qt under Android. It was the period between 2010 and 2013 and in both the cases I faced with this kind of Git approach; IMHO was the only possible way to keep under control big developer teams working on many different groups of features part of the same project like an operating system is. It was in those years I learned Git used in this extensive way and as much as I learned, as much I appreciated it.
BTW, that powerful and revolutionary SBC become a worldwide success 
Thanks for the review and heads-up.
Could you clarify which books you were looking at, as I found four titles:
by the same author and I suspect there will be a lot of duplicated content between them. Not sure if you were referring to all four or just two. (Actually I found six titles but two were the earlier 2017 editions of the same title.)
From what I've seen it is common for authors to re-write the same content but present one book in Verilog and one in VHDL. Not very helpful if you are starting out and you are unsure of whether to take the Verilog or VHDL routes. Some authors will do it within the same book with the same examples in both Verilog and VHDL which can be helpful to illustrate the differences but the book then tends to be twice the price.
I'm not surprised of the hardware logic oriented view as I suspect that a lot of readers trying to get started with FPGA design are coming from a hardware logic oriented education. (Have they started to include programmable logic devices as part of the digital electronics syllabus yet ?). However I have found this as being a bit of an issue now as the FPGA design tools appear to have started to drop the logic schematic based design tools in favour of coding straight in HDL.
I notice however that you don't suggest any alternative texts which would be a better option for starting out on. 
The best I've found so far as an entry level text is:
Digital System Design with FPGA: Implementation Using Verilog and VHDL
but it is not a cheap option, and it expects you to have access to a copy of:
Programmable Microcontrollers: Applications on the MSP432 LaunchPad
https://www.mheducation.com/highered/product/1259836193.html?exactIsbn=true
(which is equally not cheap) in order to accelerate some of the microcontroller based project designs covered there using the new-found FPGA skills.
The book also expects you to have access to not one but two different FPGA trainer boards, so quickly gets expensive to follow along, or you have to adjust the examples to work with what boards you have (not necessarily bad as it helps reinforce the learning.)
I've also found:
The Design Warrior's Guide to FPGAs
https://www.elsevier.com/books/the-design-warriors-guide-to-fpgas/maxfield/978-0-7506-7604-5
useful for some of the history of design leading up to FPGA but this is an old text and stops at around 2004.
As above, books are often tied to specific trainer boards (which can often be expensive). Some revised editions of books are still referring to trainer boards that are now no longer even available to purchase. The author appears to have just updated the text to account for recent software updates and re-published.