version control - Best practice: Want to partially pull commits with git -


i'm in charge of department webserver, has lot of small, one-page modules (most of them display dynamically-generated reports), , larger ones consist of 5-20 different html pages. of done in perl, few java helpers here , there.

there 2 servers: production one, , dev server, , it's unlikely third ever added. department wants quick turnaround times, when comes in office asking "can produce report how many foos in bar on last 12 months", want web page in production after hour or 2. don't have complicated build-and-deploy process - generally, build page on dev server, test it, git commit , git push on dev server, , git pull on production. works everybody.

now problem is, when work on bigger project, want use git changes, if don't want make them live yet. , @ same time, want able interrupt bigger project, small task, commit-push-pull small task, , omit big-project file pull. example,

git commit -m "first attempt, not finished yet" bigproject/file1 bigproject/file2 

then

git commit -m "reversed foo , bar" smallfix/file3 

and pull file3, not file1 , file2 production.

as far understand git, tags won't me, because can pull "everything precedes tag", , branching doesn't either, because i'd have commit everything, change branch, work there, commit again, change - , i'd need know branch want work on before touching code.

so right now, i'm using 2 sandboxes on same machine , use 1 short-term stuff, long-term things, doubt best way solve problem. how do "correctly" / git?

it sounds branching want. check out git flow (http://nvie.com/posts/a-successful-git-branching-model/).

what sounds you're describing wanting long-running development doesn't deployed until ready, not block release of further code because of changes. git flow (and other branching strategies) solves having feature branches merged main development branch, , further master branch releases. it's worth reading article merits of each one, short walkthrough be:

  1. i create feature branch big-project-x, branched develop.
  2. i work on project while, committing go.
  3. bob comes in says "i need report y", create report-y feature branch, taken develop , doesn't include big-project-x changes.
  4. i complete report-y, merge develop , push changes server.
  5. to make life easier merge develop big-project-x it's got latest changes.
  6. some time later finish big-project-x, merge develop , push server.
  7. celebrate!

to address of downsides mention:

  1. git commits cheap, if you're switching working on else it's idea commit anyway.
  2. if you've done load of changes , realise you're on wrong branch, may able git checkout branchname , commit, if there conflicts can use git stash, git checkout branchname followed git stash apply. stash great way store changes short time while jump around.

it take little bit of rigour habit of branching often, once used see power of git , lightweight branching model. need put effort making sure long-running branches don't go stale (merge develop), that's simplest way can suggest managing development of fast- , slow-paced items on same codebase.


Comments

Popular posts from this blog

database - VFP Grid + SQL server 2008 - grid not showing correctly -

jquery - Set jPicker field to empty value -

.htaccess - htaccess convert request to clean url and add slash at the end of the url -