>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
