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) > > > ------------------------------ > > > > > >
