5

At the moment i am doing it wrong and i work off of master and when everything is stable i create a version number and put it in the tag branch.

From my understanding most projects on github have master which is 'stable'. dev which is where all changes are being made, tag for versioning and extra branches for hotfix/patches, features i feel like doing now instead of what is being worked on and etc.

You push your master aka stable and typically on pull request if it looks ok you would pull into your master

I dont think my understanding is correct. Is there a 'standard' git workflow? Is there anything thats 'suggested'?

3 Answers3

7

This Git branching model is rather popular:

http://nvie.com/posts/a-successful-git-branching-model/

Martin4ndersen
  • 2,806
  • 1
  • 23
  • 32
3

There are popular workflows, like the one @MartyStack points out, but there's no standard one.

That's on purpose. Git is best thought of not as a DVCS but as a workflow toolkit. From it you can build any number of workflows, customized to your habits, team, and requirements.

Dan Ray
  • 21,623
  • 6
  • 63
  • 87
2

I put together a document on the git workflow we use.

http://www.skuunk.com/2014/01/our-git-workflow.html

The focus of the article is more conceptual than technical (i.e. it's not about which git commands to use, I assume you already know them). The main take home is that it helps to have somewhere for feature acceptance and build integration as opposed to just using master as the main trunk.

Tony
  • 566
  • 6
  • 5
  • The article is very good but I have a question how did you deal with demerge for example if some features while deployment they found stopper issues from a third party and they decide to release only 2 features out of 3 you will do another merge or it can be configured ? – Ahmed Salem Aug 28 '19 at 20:20