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:
- i create feature branch
big-project-x
, branched develop. - i work on project while, committing go.
- bob comes in says "i need report y", create
report-y
feature branch, taken develop , doesn't includebig-project-x
changes. - i complete
report-y
, mergedevelop
, push changes server. - to make life easier merge develop
big-project-x
it's got latest changes. - some time later finish
big-project-x
, mergedevelop
, push server. - celebrate!
to address of downsides mention:
- git commits cheap, if you're switching working on else it's idea commit anyway.
- if you've done load of changes , realise you're on wrong branch, may able
git checkout branchname
, commit, if there conflicts can usegit stash
,git checkout branchname
followedgit 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
Post a Comment