That's true. We should probably use GitHub Wiki or create a Web page to document it.
Zhang Wenli http://zhangwenli.com On Thu, Jan 31, 2019 at 2:25 AM Clement Ho <[email protected]> wrote: > The workflow in https://nvie.com/posts/a-successful-git-branching-model/ > works > too. I just want to make sure it's well documented so that contributors > know where to fork from when contributing code improvements > > On Tue, Jan 29, 2019 at 1:31 PM SHUANG SU <[email protected]> wrote: > > > 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) > > > > ------------------------------ > > > > > > > > > >
