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