Simulate a tfs style changeset in the enterprise version of github -

Simulate a tfs style changeset in the enterprise version of github -

i have 3 environments; dev, test , staging/prod. in our previous model of using team foundation server, have 3 branches of code matched each of these 3 environments.

developers work locally , when had code complete, they'd check dev branch. when checking in, tfs automatically creates called changeset. check-in kick off build of files code gets deployed dev environment.

when developer happy code in dev, they'd merge changeset test branch. they'd pull finish list of of available changesets dhad not been merged test, they'd select theirs , check test branch. again, kick off build , output files deployed test.

once qa happy changes, dev merge changeset prod branch. kicking off build , files deployed staging area. developer , qa them promote these files prod.

all of allow multiple developers work on same files using changeset mentality. when specific changeset (or set of changesets) merged environment, changes merged.

in relatively new exposure git, cannot seem find way select specific "pull requests" (which assume similar tfs changeset) 1 branch branch. when seek create pull request 1 branch branch, wants pull in not pull request, every other pull request made in lower branch other developers too. magic way create happen?

note: unfortunately don't have notion of "release". have 5 scrum teams working on 1 website on 200 pages. each scrum team has own sprints , can release multiple scrum stories during sprint. have internally 1 dev environment, , 1 test environment , 1 prod environment. not our environments used these 5 scrum teams, these dev/test/prod sites used various other teams integration efforts applications sell , client business relationship management , purchasing. cannot alter infrastructure.

note: not give-and-take if "changeset" methodology right or proper. question of how accomplish behavior in github/git.

note: set of scrum-based agile teams. work stories. many 60 stories can actively in development @ 1 time our big team of 25+ developers. when 1 story ready prod, promote prod environment atomic unit. think of changeset story.

i have 2 thoughts:

don't way. instead, should git-flow. http://danielkummer.github.io/git-flow-cheatsheet/ , http://nvie.com/posts/a-successful-git-branching-model/ explanations. @ it's core, git-flow naming convention branches, it's not tied git @ all. in essence, have feature branches each developer or dev team works on. 1 time finish feature, merge develop. develop "done features" -- not "done done" rather "feature complete." when deem time release, fork new release/someversion branch (name match release name), , work qa harden release. commits on release/someversion branch bug fixes. 1 time it's plenty deploy, fast-forward master branch release branch force production. master represents what's in production. deploy, merge release/someversion develop bug fixes mainline of development. project manager / product owner can think of develop branch "the latest," , developers can go on on feature branches until they're feature complete. (hint, create features little -- hr or day. features not releases.)

so why improve way doing it? if feature done, ready plenty qa start banging on it, it's done plenty part of next release. picking , choosing features around each other lead subtle , unpredictable bugs. since you're re-merging @ each step, have possibility you'll merge incorrectly, creating bug. you're creating unique product each step, production different set of features vetted in dev , test. (will bad things? inquire pharmacist if these drugs interact when taken together.)

git-flow works great cadences have coordinated, infrequent, larger releases. closer continuous delivery, ceremony in way. @ point, may take flip github flow or similar lighter-weight naming convention.

if you're really, really, (see above "you shouldn't way" comment) convinced should way, first, go convince rubber duck , have talked out of it. if you're still really, convinced need this, you'll need squash commits creating 1 big commit entire feature, cherry pick changeset between branches.

there's few disadvantages "squash , cherry-pick" approach. 1. lose history. since you're squashing history together, have maintain features in contained bundles, , edit bundle whole. 1 of primary premises of source command audit history -- both roll if goes wrong, , reference when need larn why works way or talk it. (see "git blame".) when squash, intentionally remove learning tool. 2. you're playing features place in different orders. you're doing merges. makes git awesome merging easy. makes git merging easy in little pieces. methodology of squashing associated feature 1 huge commit , cherry-picking between branches means you're doing big merges ... means hard.

yeah, know you're quite enamored way it's been, , don't want telling babe ugly. sorry. babe ugly. on bright side, doesn't need be. git flow awesome, , can facilitate velocity team needs.

github tfs changeset