Off-cource I did. I get mails for that ;-)
Don't panic. All is well. We all broke the build one day. That is why we
have jenkins, nightly builds, travis, gitflow, ..... ;-)
Op 6/04/2016 om 0:52 schreef Roberto Lo Giacco:
Did you notice I broke the build? I erroneously committed a file containing duplicate code due to a merge conflict: my bad, I should have run the application before submitting the pull request.
I just submitted a new one AFTER checking everything was right.
Apologies.
On Wed, Apr 6, 2016 at 12:34 AM, Jan Baeyens <jan@xxxxxxxxxx <mailto:jan@xxxxxxxxxx>> wrote:
>heck it's not going to create a mess: I don't want to break
everything
With a good version control system one should always be able to
revert :-)
I think the biggest change for gitflow is that it is not
nessesary to rebase.
Op 6/04/2016 om 0:14 schreef Roberto Lo Giacco:
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
<mailto: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
<mailto: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 <mailto:rlogiacco@xxxxxxxxx>> wrote:
I've found this
http://danielkummer.github.io/git-flow-cheatsheet/
interesting
On Mon, Mar 14, 2016 at 11:14 AM, Wim Jongman
<wim.jongman@xxxxxxxxx
<mailto: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
<mailto: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
<mailto: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
