In fact, a big APP (hundreds of engineers are working on it) we are involved in is following a workflow similar to < https://nvie.com/posts/a-successful-git-branching-model/>.
But I think there are several drawbacks if applied to echarts: (1) In this workflow, the `master` branch, which contains only some tags, is rarely concerned. But developers mostly concerns `develop` branch, based on feature branches created. In fact, the `master` branch in the workflow is similar to the current `release` branch of echarts, and the `develop` branch is similar to the `master` branch of echarts. (2) The workflow takes more extra work on merging. It is inevitable for the repo developed by many people, but is probably expensive and not necessary for some small projects like echarts. I agree that we should pay more attention to make the `master` branch keep "stable" and contains the latest "finished" changes (bug fix, new feature, ...). And based on that the `master` branch can be the base of the new dev branch. About the "release stage", it is relatively simple: By convention, the development of echarts have been following the process: develop => release => develop => ... Although there is some parallel between "develop" and "release", but generally they are linear. When a "release stage" started, a "release" branch is created and the overall regression test is performed. This stage takes at least a weak or even weeks, depending on how many changes are made and how many extra defeats are found in this stage. It also includes the voting process of ASF. After it finally released, the "release" branch is merged back to the "master" branch. ------------------------------ Su Shuang (100pah) ------------------------------ On Tue, 29 Jan 2019 at 17:22, Ovilia <[email protected]> wrote: > I don't think branches should be divided into those maintained by one > person or shared by multiple persons. > I think branches should be divided by functioning. Beside special branches > like master, release and etc., most feature-based branches should be > treated in the same way, no matter they are a small feature maintained by a > single developer, or a large one by multiple people. > > With that being said, Workflow B looks good to me, only that I think we may > have a further discussion about whether we should use master branch for > everyday development. > > To make sure master branch is more stable, would it be a better idea to use > dev branch for regular developing? See > https://nvie.com/posts/a-successful-git-branching-model/ > > Zhang Wenli > http://zhangwenli.com > > > On Mon, Jan 28, 2019 at 2:15 AM SHUANG SU <[email protected]> wrote: > > > Based on the current setting of the `echarts` repo (PR based dev), > > I think the two workflows could be used in developing: > > > > [Terminology] > > + `Public Branch`: that is the protected branch in echarts > > (master|release|protected-xxx). > > + `Private Branch`: that is the branch is only used by me, either in > > echarts repo or other cloned repo. > > > > [Issues considered] > > + This scenario should not be in a mess: created a PR but it not approved > > yet, then make new commits at local, then the PR approved and merged, > then > > pull. > > + How to sync `Public Branch` and `Private Branch` easily. > > + The commit log would look neat (Otherwise, it would be ugly that lots > of > > merge logs, and most of the key logs are not in the `Public Branch`). > > + It should not bring troubles to locating issues (such as diff log, find > > when and where some problem brought). The `Squash Merge` probably brings > > that trouble. > > > > > > --- Workflow A: dev on `Private Branch` --- > > [Workflow] > > + Dev and commit on the local `Private Branch`. Keep sync with some > `Public > > Branch` manually. > > + Create PR from the corresponding remote `Private Branch` to the `Public > > Branch`. > > + Use "normal merge" when merging PR. > > + Pull from the `Public Branch` and merge to the local `Private Branch` > if > > other commits exist. > > [Advantage] > > + Do not need to `rebase`. > > [Disadvantage] > > + Troubled by the lots of merges. > > + The commit logs of `Public Branch` does not look neat. > > [Suitable for] > > + Dev some feature independently. > > > > --- Workflow B: dev on `Public Branch` --- > > [Wrokflow] > > + Dev and commit on a local `Public Branch`. > > + Push to a temporary branch and create a PR to the remote `Public > Branch`. > > `git push origin HEAD:refs/heads/tmp-xxx` > > + Use `rebase merge` when merging the PR. > > + When intending to `pull` to local, DO NOT `pull` directly, instead, > > + `fetch orgin`, > > + `Rebase` the current local `Public Branch` to the `HEAD` of > `origin`. > > (If there are new commits created after the `push`, they will be > > `rebased` in this process) > > [Advantage] > > + The commit log of `Public Branch` looks neat. > > [Disadvantage] > > + Can not `pull` directly, but should use `fetch+rebase` instead. > > [Suitable for] > > + Fix some small problem reqidly. > > + Dev some feature collaboratively (for example, dev on branch > > `protected-xxx`). > > > > What's your opinion. It would be nice if there are any better ways. > > > > > > ------------------------------ > > Su Shuang (100pah) > > ------------------------------ > > >
