1

目前我保持本地和开发服务器环境同步的方式是使用 fabfile。

def upload():
 """ upload project dir to the production server. """
extra_opts = '--omit-dir-times'
rsync_project(
    remote_dir=env.remote_dir,
    local_dir=env.local_dir,
    exclude=RSYNC_EXCLUDE,
    delete=True,
    extra_opts=extra_opts,
)
reload_apache()

当我想从回购中提取时,我使用它

def update_source():
    """ Update the project source. """
    with cd(env.directory):
        run('hg fetchanddestroy')

该别名 cmd 执行此操作的位置

fetchanddestroy = !hg pull && hg update -C

如何在 bitbucket 上将一系列变更集合并为一个?我尝试过使用 machg,但它只是拉回了我合并的所有内容。我正在尝试用一种合适的方式在我的 VPS 上部署我的项目,并使它们与我的本地存储库保持同步。在设置环境的过程中,我不得不对 repo 进行细微的调整,这导致在服务器上进行了许多变更集并拉取。因此,我想将所有这些小的变更集合并为一个,以保持我的回购历史干净。

谢谢

4

1 回答 1

1

Not sure I completely understand what you are asking but using a branch workflow similar to Git Flow is a good way to manage the flow of changes between development and release.

In "short",

  • keep all releases in a branch called master
  • do all your development in default as you normally would
  • at release time create a branch off of master for the release

    $ hg update master && hg branch relv1.0

  • merge in what you want from default, for this example assume the latest is what you want.

    $ hg merge default && hg commit -m "merge latest from default"

  • if necessary make changes in this branch to make tests pass if applicable and in general get it ready for release whatever that means for your project.

    $ hg commit -m "last minute bug fix...etc"

  • When you are confident that the release is ready, tag it, close the branch and merge it into master.

    $ hg tag "release 1.0" && hg update master && hg merge "release 1.0" && hg commit -m "merge release 1.0"

    $ hg update "release 1.0" && hg commit --close-branch -m "all done"

  • and finally get default back in sync with master.

    $ hg update default && hg merge master # there's a possibility of merge conflicts here, if you have multiple people doing development

    $ hg commit -m "merge release 1.0 from master"

  • for deployment, you could just pull latest from master

The overall effect here is that the diff going into master should always represent the combined changes from the default branch since the last release which I think is what you want instead of all the individual changesets that led up to that release.

Obviously there's probably 1000 ways to do it, but I think it's a safe bet that a branching strategy like Git-Flow is ubiquitous enough that your team can understand it and thus follow it.

Another option is using patch queues, that way you have complete control of what goes into a changeset at any given point.

于 2012-04-23T12:15:02.583 回答