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.

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.

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

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.

I'm wrong all the time. Ask my spouse. Why so sensitive?

By your own admission you have minimal experience in Git. I suspect I have less than you. Chances are you might be wrong. The responder interpreted the documentation to suggest your perspective is not correct. It wasn't as though the comments were derogatory or disrespectful. I would expect with a level 8 ranking on the site you have seen worse.

If you are suggesting there are comment vultures sitting waiting for the chance to feed on a wrong response, I say there are few. Those that exist, I suggest are pretty thin because they are not feeding that well. My experience doesn't give me indication they are in abundance on the site.

Looking at your background profile and experience I think you might have some insight that would be of benefit to the community. It is unfortunate we don't have rules of conduct that are more to your liking but that is not surprising. With of 200K members someone is bound to get pissed at something. Confirmation bias will enable you to find details to support your wish to not participate.

I have been asked to change comments on posts. After asking for clarification from the moderator, I have refused. I accept the moderator has the right to remove what someone interprets as inappropriate. That doesn't mean I have to agree.