opps I was so excited I already started to use gitflow in my fork...
but if I undersatnd correctly how it works I can merge both features into
my develop branch and submit a pull request from me/develop toward
you/master
let's give the latter a try, but please double check it's not going to
create a mess: I don't want to break everything
On Tue, Apr 5, 2016 at 11:37 PM, Jan Baeyens <jan@xxxxxxxxxx> wrote:
Just push your changes.
I think we need a good understanding before we go to the gitflow approach.
Naming conventions and other stuff. As gitflow introduces some sort of
release management I feel it is important to release early and soon to get
the change spread to other users/systems. After all we are still basically
3.
As the master already contains lots of changes master = development. As
you changes are "good enough for testing/sharing" they should be in
development.
I just wish we already had a hotfix for the where sh and multi private
libraries issues.
Op 5/04/2016 om 23:22 schreef Roberto Lo Giacco:
If we all agree I'll start using git flow immediately and create a feature
for *serial-monitor*.
I already have the library manager into my master: if you wish I can
export my commits to patch files and restart my fork clean....
Just let me know: I'm eager to submit my changes into the nightly :-)
On Tue, Apr 5, 2016 at 7:12 PM, Jan Baeyens <jan@xxxxxxxxxx> wrote:
Finally had some time to look at this gitflow thing. my remarks:
1:Looks much like how I have advised my customers years ago to use RTC.
2:Sorry for missing the 1th of April start date
3:I'm in.
Jantje
Op 14/03/2016 om 13:01 schreef Wim Jongman:
and this [1] (Eclipse integration)
[1]
http://eclipsesource.com/blogs/2015/06/22/git-flow-top-eclipse-mars-feature-3/
On Mon, Mar 14, 2016 at 11:59 AM, Roberto Lo Giacco <
<rlogiacco@xxxxxxxxx>rlogiacco@xxxxxxxxx> wrote:
I've found this <http://danielkummer.github.io/git-flow-cheatsheet/>
http://danielkummer.github.io/git-flow-cheatsheet/ interesting
On Mon, Mar 14, 2016 at 11:14 AM, Wim Jongman < <wim.jongman@xxxxxxxxx>
wim.jongman@xxxxxxxxx> wrote:
More read here [1]
[1] https://leanpub.com/git-flow/read
On Mon, Mar 14, 2016 at 10:42 AM, Roberto Lo Giacco <
<rlogiacco@xxxxxxxxx>rlogiacco@xxxxxxxxx> wrote:
Count me in if Jantje is willing to go down that route
On Mon, Mar 14, 2016 at 9:46 AM, Wim Jongman < <wim.jongman@xxxxxxxxx>
wim.jongman@xxxxxxxxx> wrote:
Jantje has been working on the bigChange branche for quite some time
whilst hot fixes where pushed to master. Maybe you are not aware of this
but a lot of people have been discovering this workflow. This has
resulted
in a bunch of git commands that are now known as *Git Flow*.
Git Flow has support in Eclipse. It works like this:
There are two main branches, *master* and *develop*. The develop
branch has the exact same purpose as Jan's bigChange branch. It enables
you
to make big changes without loosing track of what the people are using.
It
is used to work towards a new release. *Nightly* should be build
from *develop* and *release* should be build from *master.*
*Is this all?*
Yes and no. Yes, in that this is the essence of Git Flow. No because
why would you want to make it simple.. Before I tell you about the other
nice features. I have to explain one term that Git Flow uses:
*Feature*. A features is basically a new fix, an added function,
etc..
The other principles Git Flow has are:
* All changes are done in *Feature Branches* which are typically
named after the issue number (e.g. 321, 332, etc..)
* When a feature is done, it is merged back into the develop branch
(and a new nightly is build).
* All changes to master are done in *Hot Fix* branches,
* When a hot fix is done, it is merged back into master (and a new
release is build)
*I propose to move over to the** Git Flow principle **after April 1.*
I am more than happy to give a lesson about git and git flow. Life is
so much more beautiful when you get git than if you "just use it" without
fully understanding it.
Cheers,
Wim
