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.

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 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.

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.

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

Jon,

Branch strategy is an entirely separate topic.  Branching depends on the development environment and the branch strategy.

I am sorry but this is totally wrong. Not just IMHO, it is wrong as you read the basis of the Git features and behavior. What is TOTALLY another topic is Agile as well as the tons of other team development methodology. All of them – it is the current trend – tend to abandon SVN and other source control methods moving to Git.

A COLLATERAL but not totally different topic instead is the Git platforms you mention: GitHub (I use for open source) GitLab (I own my license on my AWS server as well as another GitLab for company Git development) and many other; for example, Qt development has its own report. Those you mention are just the most popular, GitHub on top of them.

developers should not push remotely their local Git database it is just an option when they work on teams, need to share with company or colleagues their development, and so on. As I told these are just tools and options where you can store Git on the cloud. I have tons of my Android development repositories I stored privately on my own AWS server as my local and remote collaborators were accessing the same, using online git commands and SSH for remote connection.

Enrico

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

balearicdynamics  wrote:

 

Jon,

Branch strategy is an entirely separate topic.  Branching depends on the development environment and the branch strategy.

I am sorry but this is totally wrong. Not just IMHO, it is wrong as you read the basis of the Git features and behavior. What is TOTALLY another topic is Agile as well as the tons of other team development methodology. All of them – it is the current trend – tend to abandon SVN and other source control methods moving to Git.

 

Yeah, of course I am wrong on this forum.  It's not like I have to deal with this on a daily basis in my day job.  But. hey, thanks again for reaffirming for why I limit my posts here and seriously why I don't like coming to this site anymore. 

Cheers.

You expressed an opinion if I am not wrong. Me too. Both are valid, maybe criticizable.

That's all.