views:

81

answers:

2

I have a production website where master is checked out and a development webiste where I develop in feature branches.

When a feature is merged into master I do this on the development site:

(currently on the new-feature branch)
$ git commit -m"new feature finished"
$ git push
$ git checkout master
$ git merge new-feature
$ git push

And on the production site:

(currently on master branch)
$git pull

This works for me. But sometimes the client calls and needs a small change on the website quickly. I can do this on production on master and push master and this works fine.

But when I use a feature branch for the small change I get a gap:

(On production on branch master)
$ git branch quick-feature
$ git checkout quick-feature
$ git push origin quick-feature
$ edit files...
$ git add .
$ git commit -m"quick changes"
$ git push # until this point the changes are live
$ git checkout master #now the changes are not live anymore GAP
$ git merge quick-feature # now the changes are live again
$ git push

I hope I could make clear the intention of this workflow. Can you recommend something better?

A: 

if your quick-feature branch is developed on top of master, you could reset the master branch while still being in the quick-feature branch:

git branch -f master

That way, you avoid the checkout master which removes temporarily from your working tree the quick-feature.

x--x--x  (master)
       \                          => x--x--x--f--f--f--f (master, quick-feature)
        -f--f--f (quick-feature)

Another solution, when you switch back to master, is to ask for a merge

 git checkout --merge master

That allows you to keep quick-feature modification while taking into account the current state of master.

VonC
thanks a lot. and the drawings really help. - karthorwald - aka
what does git really do in the second version "git checkout --merge master"? if i were git i would just do behind the curtain what version 1 is "git branch -f master"? - karthorwald - aka
@user89021: the checkout step is needed if `master` had some evolutions while `quick-feature` was being done. If no evolutions on `master`, then you can indeed simply reset `master` on `quick-feature` HEAD.
VonC
i tried this for the first time now: icommited quick-feature, then said "git checkout -m master" but quick-feature files were gone then. i got master like it was before.
@user89021: normal, it only deals with the index files, not the committed files from quick-feature. If master was not modified, could you try the first option? `git branch -f master`
VonC
@user89021: I meant working tree, not index. `checkout -m` merge local modifications. It removes however any committed content which is not part of the branch being switched to.
VonC
OK, I see I have to invest more learning time here. I will go with git branch -f master for now, which does what I need. Thanks a lot! karlthorwald - aka
(it works for me because I do not modify master in the meantime in this setup usually and qucik-feature is a direct descendant from master)
A: 

"making the change on production" is just plain wrong, you shouldn't be doing that.

The correct workflow would be: - checkout master on a test/devel site/sandbox/server/whatever - make change, test change - commit change, merge into master, deploy in production

that's what branches are for. You could even make your workflow more automatic by using hooks in git that will automagically deploy in production everything you 'git push' to a specific branch, which may be the master one or another dedicated branch.

Luke404
yes, i gree with that. it is a bad habit and i should setup a third environment for such cases - karlthorwald - aka