GIT course

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.

Well, I think what you are describing are two separate things. Git is just a tool used to move code to a repo and such.

Branch strategy is an entirely separate topic.  Branching depends on the development environment and the branch strategy.  Most Agile Development encourages pushing changes often to ensure the code is not lost.  However, the idea is to create a development branch and to create feature branches for particular issues where a developer works from and can push changes to.   Once the code is ready to be pushed to the development branch, a code review would be created and the code goes under scrutiny.  In some instances code analysis would take place as the code is pushed to ensure there are no syntax issues or spacing issues as in Python. Once the code has gone through a code review, then a pull request would be mode to merge the code into the development branch.   This continues until there is a release set and all fhe changes are properly merged into the development branch where the code is merged into the master branch.  In some cases a release branch would be made and only select changes are checked into the master branch.  This is just one scenario and could take many forms.

There are many tools to keep repos in such as GiHub, GitLab, Bitbucket and the old ClearCase.

This is a deep topic, and could git nasty.

We do almost as you explain, except the review.

That doesn't happen before the pull request, but as part of the pull request approval.

If the review passes, the reviewer approves the pull request.

If not, they use the code comment functionality in devops and reject.

The developer can then fix code in the existing feature branch. Those commits get automatically added to the pull request when pushed.

The approval count is reset and the review can proceed...

I've been in environments where Crucible was used for code review before the pull request to keep the pull request clean.

Also, at Intel, the code went through an analyzer and linter when pushed to a branch and would get rejected if there was a failure and everyone assigned to the project got an email of said incident.

But, then again, there are folks that still use SVN over Git.

I've been in environments where Crucible was used for code review before the pull request to keep the pull request clean.

Also, at Intel, the code went through an analyzer and linter when pushed to a branch and would get rejected if there was a failure and everyone assigned to the project got an email of said incident.

But, then again, there are folks that still use SVN over Git.

inspired by the discussion, I'm turning the firmware repo for my dc load into a managed project, with branch policies.

I've been the only committer for this project and for these situations I just create a master branch with commit rights (all my github repos are currently set up like this).

But I can create a project with board for issue and pull request management, and fiddle out how branch policies work in git.

Then switch my local repo over to a development branch ...

Here's the locaton: https://github.com/jancumps/msp432/projects/1