<div dir="ltr">Thanks, we are familiar with GitFlow, and have decided against using it. We find it doesn't reflect our relationship to branches and feature work. Working with PRs directly against master is ~always what we want, and it is only for unusually long-running changes that we have a need for a feature branch, and there is no distinction between develop and master.<div><br></div><div>-MinRK</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 29, 2015 at 11:28 AM, Wes Turner <span dir="ltr"><<a href="mailto:wes.turner@gmail.com" target="_blank">wes.turner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">With the HubFlow (GitFlow) branch structure, I think this would look something like:<div><br></div><div>- master (lastest tagged stable release)</div><div>- develop (stable trunk)</div><div>- feature</div><div> - feature/phosphor (rebase -i develop)</div><div>- hotfix/ (-> master, -> develop)</div><div> - hotfix/docs</div><div>- release/</div><div><br></div><div><br></div><div>cc'ing from <a href="http://westurner.org/tools/#hubflow" target="_blank">http://westurner.org/tools/#hubflow</a><br></div><div><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">.. index:: HubFlow
.. _hubflow:
HubFlow
~~~~~~~~~
| Src: <a href="https://github.com/datasift/gitflow" target="_blank">https://github.com/datasift/gitflow</a>
| Docs: <a href="https://datasift.github.io/gitflow/" target="_blank">https://datasift.github.io/gitflow/</a>
| Docs: <a href="https://datasift.github.io/gitflow/IntroducingGitFlow.html" target="_blank">https://datasift.github.io/gitflow/IntroducingGitFlow.html</a>
| Docs: <a href="https://datasift.github.io/gitflow/TheHubFlowTools.html" target="_blank">https://datasift.github.io/gitflow/TheHubFlowTools.html</a>
HubFlow is a fork of GitFlow
that adds extremely useful commands for working with Git and GitHub.
HubFlow is a named branch workflow with mostly-automated merges
between branches.
Branch names are configurable; the defaults are as follows:
+--------------------+-------------------------------------------------------------------------+
| **Branch Name** | **Description** |
| | (and `Code Labels <<a href="https://westurner.org/wiki/workflow#code-labels" target="_blank">https://westurner.org/wiki/workflow#code-labels</a>>`__) |
+--------------------+-------------------------------------------------------------------------+
| ``master`` | Stable trunk (latest release) |
+--------------------+-------------------------------------------------------------------------+
| ``develop`` | Development main line |
+--------------------+-------------------------------------------------------------------------+
| ``feature/<name>`` | New features for the next release (e.g. ``ENH``, ``PRF``) |
+--------------------+-------------------------------------------------------------------------+
| ``hotfix/<name>`` | Fixes to merge to both ``master`` and ``develop`` |
| | (e.g. ``BUG``, ``TST``, ``DOC``) |
+--------------------+-------------------------------------------------------------------------+
| ``release/<name>`` | In-progress release branches (e.g. ``RLS``) |
+--------------------+-------------------------------------------------------------------------+
Creating a new release with :ref:`Git` and HubFlow:
.. code:: bash
git clone ssh://<a href="http://git@github.com/westurner/dotfiles" target="_blank">git@github.com/westurner/dotfiles</a>
# git checkout master
git hf init
## Update versiontag in .git/config to prefix release tags with 'v'
git config hubflow.prefix.versiontag=v
#cat .git/config # ...
# [hubflow "prefix"]
# feature = feature/
# release = release/
# hotfix = hotfix/
# support = support/
# versiontag = v
#
git hf feature start ENH_print_hello_world
## commit, commit, commit
git hf feature finish ENH_print_hello_world # ENH<TAB>
git hf release start 0.1.0
## commit (e.g. update __version__, setup.py, release notes)
git hf release finish 0.1.0
git hf release finish 0.1.0
git tag | grep 'v0.1.0'
The GitFlow HubFlow illustrations are very helpful for visualizing
and understanding any DVCS workflow:
`<<a href="https://datasift.github.io/gitflow/IntroducingGitFlow.html" target="_blank">https://datasift.github.io/gitflow/IntroducingGitFlow.html</a>>`__.</pre><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap"><br></pre><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">****** <span style="font-family:arial,sans-serif">with HTML formatting *****</span></pre></div><div><br></div><div><pre style="overflow:auto;font-family:Menlo,Monaco,Consolas,'Courier New',monospace;font-size:13px;padding:9.5px;margin-top:0px;margin-bottom:10px;line-height:1.42857143;color:rgb(51,51,51);word-break:break-all;word-wrap:break-word;border:1px solid rgb(204,204,204);border-radius:4px;background-color:rgb(245,245,245)">git clone ssh://<a href="http://git@github.com/westurner/dotfiles" target="_blank">git@github.com/westurner/dotfiles</a>
# git checkout master
git hf init
## Update versiontag in .git/config to prefix release tags with 'v'
git config hubflow.prefix.versiontag=v
#cat .git/config # ...
# [hubflow "prefix"]
# feature = feature/
# release = release/
# hotfix = hotfix/
# support = support/
# versiontag = v
#
git hf feature start ENH_print_hello_world
## commit, commit, commit
git hf feature finish ENH_print_hello_world # ENH<TAB>
git hf release start 0.1.0
## commit (e.g. update __version__, setup.py, release notes)
git hf release finish 0.1.0
git hf release finish 0.1.0
git tag | grep 'v0.1.0'</pre></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 29, 2015 at 1:15 PM, Brian Granger <span dir="ltr"><<a href="mailto:ellisonbg@gmail.com" target="_blank">ellisonbg@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am +1 on having separate branches for ongoing 4.x work that include<br>
more than just bug fixes - especially for the notebook and widgets. I<br>
have a slight preference to have master always be the newer stuff, but<br>
don't feel too strongly about that.<br>
<div><div><br>
On Mon, Jun 29, 2015 at 10:54 AM, Jonathan Frederic<br>
<<a href="mailto:jon.freder@gmail.com" target="_blank">jon.freder@gmail.com</a>> wrote:<br>
>> I wanted to +1 the proposal to start creating branches for new versions<br>
>> when a feature freeze occurs.<br>
><br>
><br>
> +1 here too, I'm going to do that with ipywidgets for SciPy, create a 5.x<br>
> branch. There's a lot of stuff I want to get a jump start on, and SciPy is<br>
> a great time to do it. I don't want it to end up like numerous other<br>
> experiments, which end up getting thrown out and redone completely just<br>
> because of stagmentation and rebase difficulty.<br>
><br>
> WRT to the documentation debt, I think it's important to remind everyone<br>
> that that is intentional! I've looked at adding JS docs a couple times now,<br>
> but when I brought it up we've decided as a group that it was lower priority<br>
> because we did not want to commit JavaScript APIs that we know will change.<br>
><br>
> I think when we figure out how the front-end packaging and component<br>
> refactor will work, we definitely want to commit to **something**.<br>
><br>
> On Mon, Jun 29, 2015 at 7:04 AM, Sylvain Corlay <<a href="mailto:sylvain.corlay@gmail.com" target="_blank">sylvain.corlay@gmail.com</a>><br>
> wrote:<br>
>><br>
>> I wanted to +1 the proposal to start creating branches for new versions<br>
>> when a feature freeze occurs. Independently of the discussion on phosphor, I<br>
>> completely agree with Min on the diagnosis that there is not enough<br>
>> available parallel work.<br>
>><br>
>> Regarding phosphor and the work on refactoring the front-end, thanks for<br>
>> creating the centralized phosphor notebook repository in the organization. I<br>
>> did some experiments lately with the widgets and did not know where this<br>
>> could fall, or how to share it without requiring it to install phosphor etc.<br>
>> Coordination is also important for new developments, even when they have not<br>
>> yet achieved the stability of the main components of the project.<br>
>><br>
>> Best,<br>
>><br>
>> Sylvain<br>
>><br>
>><br>
>><br>
>> On Mon, Jun 29, 2015 at 9:25 AM, Jason Grout <<a href="mailto:jason@jasongrout.org" target="_blank">jason@jasongrout.org</a>> wrote:<br>
>>><br>
>>> On 6/26/15 19:45, Fernando Perez wrote:<br>
>>><br>
>>> While I hear very much the spirit of what you are saying, and I<br>
>>> certainly think that we can't lose sight that the *only* thing that<br>
>>> ultimately matters is whether we serve our users well or not, there's a<br>
>>> big piece that is already burning under us that probably can't wait. In<br>
>>> fact, at the last dev meeting, Jason already posted his new draft code<br>
>>> in this direction:<br>
>>><br>
>>> <a href="https://github.com/jasongrout/phosphor-notebook" rel="noreferrer" target="_blank">https://github.com/jasongrout/phosphor-notebook</a><br>
>>><br>
>>><br>
>>> I just wanted to mention that I support what Fernando, Brian, and Chris<br>
>>> have said about moving forward with refactoring the notebook. We're making<br>
>>> good progress, even while still ramping up. For example, Steven Silvester<br>
>>> has put a lot of work recently in porting over the kernel javascript to<br>
>>> Typescript and phosphor (along with dependencies):<br>
>>><br>
>>> <a href="https://github.com/jasongrout/phosphor-notebook/pull/2" rel="noreferrer" target="_blank">https://github.com/jasongrout/phosphor-notebook/pull/2</a><br>
>>><br>
>>> I just put in an in-progress pull request for documenting the API for<br>
>>> kernels, kernelspecs, and sessions (which I realized when looking at the<br>
>>> kernel javascript file was woefully undocumented/incorrectly documented):<br>
>>> <a href="https://github.com/jupyter/notebook/pull/173" rel="noreferrer" target="_blank">https://github.com/jupyter/notebook/pull/173</a>. This shows our refactoring<br>
>>> work is also having an immediate direct impact on the current notebook as<br>
>>> well.<br>
>>><br>
>>> In another message on this thread, Min suggested having a 5.x branch for<br>
>>> further development, like the phosphor notebook. For now, I think the<br>
>>> phosphor notebook can proceed as a separate project - it's totally a<br>
>>> front-end thing at this point, and we're doing enough code clean-up and<br>
>>> rewriting from js to typescript that I think it's all right to start in a<br>
>>> fresh repo. Which brings up another point: can we make an official Jupyter<br>
>>> repo for the phosphor notebook work, rather than using my personal repo?<br>
>>> I'm happy to continue hosting<br>
>>> <a href="https://github.com/jasongrout/phosphor-notebook/" rel="noreferrer" target="_blank">https://github.com/jasongrout/phosphor-notebook/</a> in my personal github<br>
>>> account for the time being, or set up a temporary organization so we can<br>
>>> collaborate more effectively, but I think it would make more sense to bump<br>
>>> it up to an experimental repo in the jupyter github organization, developed<br>
>>> in parallel with the current notebook.<br>
>>><br>
>>> Thomas, one thing to consider is that us working on a phosphor notebook<br>
>>> doesn't preclude interested people from enhancing the existing notebook in<br>
>>> the short term. We'd like the phosphor notebook to get to a comparable<br>
>>> state with the current notebook as quickly as possible, but it will still<br>
>>> take some time.<br>
>>><br>
>>> Also, I totally agree with Thomas that dogfooding the notebook (and<br>
>>> watching/helping others actually use it to get work done) is *extremely*<br>
>>> important to understanding what we want here. And I also agree with others<br>
>>> on this thread that documentation is sorely lacking. We'll be working on<br>
>>> that in the phosphor notebook as we go along too.<br>
>>><br>
>>> Thanks,<br>
>>><br>
>>> Jason<br>
>>><br>
>>> _______________________________________________<br>
>>> IPython-dev mailing list<br>
>>> <a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
>>> <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" rel="noreferrer" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> IPython-dev mailing list<br>
>> <a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
>> <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" rel="noreferrer" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> IPython-dev mailing list<br>
> <a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" rel="noreferrer" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
><br>
<br>
<br>
<br>
</div></div><span>--<br>
Brian E. Granger<br>
Cal Poly State University, San Luis Obispo<br>
@ellisonbg on Twitter and GitHub<br>
<a href="mailto:bgranger@calpoly.edu" target="_blank">bgranger@calpoly.edu</a> and <a href="mailto:ellisonbg@gmail.com" target="_blank">ellisonbg@gmail.com</a><br>
</span><div><div>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" rel="noreferrer" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" rel="noreferrer" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></blockquote></div><br></div>