CODEWITHSUNDEEP
gitversion-controlworkflowstaging
Jeff Storey
Jeff Storey

Reputation: 57162

git staging server

We are working on setting up a git environment, and for our workflow, we would like to do the following:

enter image description here

The issue is that I want to be able to easily pick and choose which changes I want to push to production from staging. For example, if dev1 is working on feature 1 and dev2 is working on feature 2, I might only want to push the changes of feature 1 to production. Is this possible? I might even have a case where dev1 is working on feature 3 and feature 4, but I only want to push feature 4 to production.

Upvotes: 1

Views: 485

Answers (3)

Kevin Bedell
Kevin Bedell

Reputation: 13404

This is very common. I do this frequently.

The approach to use is to have developers create what are called feature branches (or just branches.

This is done using the command:

git checkout -b my_new_feature

Then they can work on the feature and everyone else can get that code, but it won't mix with any other branches until that branch is merged into your master branch, like so:

git checkout master
git merge my_new_feature

Different developers can work on different features however long it takes, then you can merge to master (and push to staging) whenever it makes sense.

Upvotes: 1

Andy Ross
Andy Ross

Reputation: 12033

It's probably easiest for each developer to maintain their own branch, which they are responsible for keeping updated to current versions of your master branch. Or even one branch per "feature that is a distinct merge candidate". Then you, as owner of the production branch, get to choose which branches to merge, and when. Having everyone pushing into a shared staging tree which you dont use a simple one-way stage on the way to production sounds like a recipe for mistakes.

Upvotes: 1

Adrian Cornish
Adrian Cornish

Reputation: 23848

Checkout this

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

Upvotes: 2

Related Questions