17 Feb
2014
17 Feb
'14
4:33 p.m.
As we talked with Guido we are taking an article [0] as inspiration as
branching strategy, here i would comment something about it
[0] Says:
Feature branches typically exist in developer repos
only, not in origin.
I think this is not a good idea in our situation, we are a bunch of developer
around the world and some time we don't know well on what the other are
working, keeping those branch in origin and WELL UPDATED would help in
understanding what is happening, to avoid work duplication and consequent hard
to impossible to resolve merge conflict.
[0] Says:
Finished features may be merged into the develop
branch definitely add them
to the upcoming release:
...
$ git merge --no-ff myfeature
...
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
The --no-ff flag causes the merge to always create a new commit object, even
if the merge could be performed with a fast-forward. This avoids losing
information about the historical existence of a feature branch and groups
together all commits that together added the feature.
I think it is better do not delete the feature branch by default, and
eventually delete just if necessary, so to keep better tracking of edit
history and isolate easily eventual regressions, and i think the same about
release and htofix branches, so generally i wouldn't delete branch if not
necessary
[0] http://nvie.com/posts/a-successful-git-branching-model/
18 Feb
18 Feb
12:35 a.m.
On Monday 17 February 2014 17:33:15 Gioacchino Mazzurco wrote:
keeping those branch in origin and WELL UPDATED
If I wasn't enough clear, I mean that each of us should push as soon as have
something committed (I usually push for each commit i do), to make easier to
follow what is happening to the others :)
1:11 a.m.
Gioacchino Mazzurco <gio(a)eigenlab.org> writes:
On Monday 17 February 2014 17:33:15 Gioacchino
Mazzurco wrote:
hi, we have been using gitflow[0] with good results, and it also allows
publishing feature branches :)
the feature branches are removed when closed/merged, but the --no-ff
makes it easy to spot where a commit comes from because it's not fast
forwarded to the develop branch. i mean you can see it with a pretty
git log command or visualizers like tig.
[0]: https://github.com/nvie/gitflow
--
:>
keeping those branch in origin and WELL UPDATED
If I wasn't enough clear, I mean that each of us should push as soon as have
something committed (I usually push for each commit i do), to make easier to
follow what is happening to the others :) 
19 Feb
19 Feb
2:11 p.m.
New subject: About branching strategy: adopted nvie model
On 02/17/2014 10:11 PM, Nicolás Reynolds wrote:
Gioacchino Mazzurco <gio(a)eigenlab.org> writes:
Really nice Nicolas, thanks!
i've adopted it without effort, and it helped me keep things tidy
i've back-tagged the two de-facto "releases" we had last year, (IS4CWN
demo and hackgaraiak incidental mesh) and started a simple
release-tagging scheme
X.Y where X is major version bump, and Y is incremented with each hotfix
branch merge.
we might change that in the future (i'd love to see a v1.0 ;) ) but i
think it works for now.
With gio we have agreed on IRC to follow the nvie.com guidelines (either
manually and/or using git-flow)
and after tidying up a little bit of the past mess, we're working on our
own feature branches already succesfully
https://github.com/libre-mesh/lime-packages/branches
the convention adopted is exactly what's outlined at nvie.com (including
branch naming)
so master is normally untouched, every commit/merge there means a
release, and requires tested working code
and develop (or more likely, feature branches based off develop) is
where daily commits happen.
git clone https://github.com/libre-mesh/lime-packages/
should give you the last "stable" release
and
git clone -b develop https://github.com/libre-mesh/lime-packages/
should give you a more recent, maybe broken version.
cheers!
guit
On Monday 17 February 2014 17:33:15 Gioacchino
Mazzurco wrote:
hi, we have been using gitflow[0] with good results, and it also allows
publishing feature branches :) keeping those branch in origin and WELL UPDATED
If I wasn't enough clear, I mean that each of us should push as soon as have
something committed (I usually push for each commit i do), to make easier to
follow what is happening to the others :)
3958
days inactive
3960
days old
3 comments
3 participants
participants (3)
-
Gioacchino Mazzurco -
Gui Iribarren -
Nicolás Reynolds