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 …..
There are two points that I saw many developers always ignore or not consider in Gip version control.
1. Repository push should NOT happen only when your program works but when you make a meaningful step
2. How to manage different branches.
And, IMHO, these are the two most important possibilities from Git to keep a serious development history of your job.
We use a single repository for a project.
No one can commit/push to the master or development branch.
Developers clone from master or project, depending if it is prod support work or project development.
then create a future branch and commit and push to that very often.
When developers are ready with the work, they create a pull request (we use azure devops for that).
Code is reviewed by someone from QA team, then approved for merge by master or project branch owner.
Both these activities are done in azure devops' pull request flow. Managed by notifications.
A developer can also be a reviewer or branch owner, but can't review or approve their own pull requests.
When the pull request is approved, the feature branch is deleted, because its complete and no longer needed.
Commits and pull requests stay in the system forever.
As a daily activity, I synchronise all approved master pull requests with the development branch and inform the developers of the changed sources.
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
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