You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@echarts.apache.org by SHUANG SU <su...@gmail.com> on 2019/01/27 18:15:33 UTC
[Discussion] About the PR based dev workflow
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)
------------------------------
Re: [Discussion] About the PR based dev workflow
Posted by Clement Ho <cl...@gitlab.com.INVALID>.
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 <ov...@gmail.com> 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 <su...@gmail.com> 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)
> > ------------------------------
> >
>
Re: [Discussion] About the PR based dev workflow
Posted by Ovilia <ov...@gmail.com>.
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 <cl...@gitlab.com.invalid>
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 <su...@gmail.com> 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 <ov...@gmail.com> 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 <su...@gmail.com>
> > 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)
> > > > ------------------------------
> > > >
> > >
> >
>
Re: [Discussion] About the PR based dev workflow
Posted by Clement Ho <cl...@gitlab.com.INVALID>.
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 <su...@gmail.com> 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 <ov...@gmail.com> 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 <su...@gmail.com>
> 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)
> > > ------------------------------
> > >
> >
>
Re: [Discussion] About the PR based dev workflow
Posted by SHUANG SU <su...@gmail.com>.
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 <ov...@gmail.com> 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 <su...@gmail.com> 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)
> > ------------------------------
> >
>
Re: [Discussion] About the PR based dev workflow
Posted by Ovilia <ov...@gmail.com>.
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 <su...@gmail.com> 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)
> ------------------------------
>