8
votes

Pretty sure I'm misunderstanding git.

My goal

  • I have a private repo on github with a "master" branch.
  • I would like to also have a production branch, which I will push all my changes from master to.
  • I would then like to connect it to Azure and tell Azure to automatically deploy from the production branch.

Question

How do I best accomplish this? Initially I was thinking it was with "git push", but I believe that's for remote repositories, and so I'm now wondering what the best practice is to merge the "master" branch to the "production" branch.

Or, am I thinking about the whole thing wrong?

Thanks -- looking forward to putting my Subversion days behind me.

3

3 Answers

3
votes

(Since I am suppose to share a "wealth of information" ;) ...)

What you are looking at, when talking about master and production branches, is a merge workflow.

You can define the workflow you need with any Version Control System tool you want, and in term of development lifecycle management, one of the most complete set of merge workflow set is described in this TFS (Team Foundation Server) set, detailed in its TFS Brancing Guide and illustrated in this question "Servicing Branch in Standard Branch Plan".
Closer to git, git flow is another merging workflow quite popular.

But you are using a DVCS, and its distributed aspect introduces another (orthogonal) workflow: a publication one (your git push -u origin prod). See "Source Control - Distributed Systems vs. Non Distributed - What's the difference?"

Publication, part of release management, is quite different from merge, part of development.
By merging master to prod, you freeze what has been consolidating in development, and mark it as to be released.
By pushing it to GitHub, you start that release process.

2
votes

When your master branch is ready to be put in production, you merge it to the production branch, and then push this production branch to the github repo.

2
votes

I would suggest you take a look at the git pages for branching workflows to establish your repository management plan. Further, Von C shares a wealth of information on the git ecosystem. Browsing his answers may be prove very useful. This post is also extremely helpful for tracking remote branches.