I don't think that we should be encouraging dev on `Private Branch` as it reduces the opportunities for collaboration. Getting early feedback and allowing the community to see what you are working on is very helpful imo.
I work at GitLab and at GitLab, we do our best to make sure that `master` branch always contains the latest changes and is stable (no failing tests, passes CI pipeline). Team members create branches off `master` on a regular basis to create their fixes and push those up to the repository as public branches. These branches are sometimes maintained by one person and sometimes collaborated across multiple people. In terms of collaboration in branches, it is easier to merge `master` into those branches rather than rebasing (especially if there is a bigger divergent in the commit history). I tend to prefer that. In terms of developing on your own branches, rebasing is about the same level of effort as merging `master` to keep your branches in sync. I'm also curious to understand more about the release process of ECharts as I am not able to see that documented anywhere and Wenli recommended I continue that discussion here. On Tue, Jan 29, 2019 at 3:22 AM 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) > > ------------------------------ > > >
