You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2012/08/09 00:50:59 UTC
How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
On 8/8/12 3:19 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> No one has yet answered this:
> How can you merge from unstable to trunk persons A changes when the unstable
> branch contains persons A, B, C, D, E and F changes and each person may of
> made multiple check ins at different (overlapping) times?
>
> As far as I'm aware you can't do this via revision numbers. If you think it
> can be done (via revision numbers or some other way) please give me a sample
> sequence of SVN commands that would achieve it.
You specify the revision number in the merge command. If A did revision 100
and B did 101 etc, you would do (from within your working copy of trunk):
svn -merge -c 100 unstable-branch-url
>
> If we do go down the path of having a single unstable branch. What I think is
> likely to happen is that as more and more changes are added to unstable it
> will become harder and harder to merge any persons changes with trunk, this
> will cause delays with releases and waste time with committers having to fight
> with SVN.
Hopefully, the net of changes to unstable eventually end up in trunk so the
two don't get too far out of sync. Even unstable shouldn't contain really
unstable stuff. Maybe it should be called "unsure". I also think this
works in part because there is no serious changes going into trunk that
didn't go into unstable first. Trunk is generally only changed by merges
(except maybe for version numbers and readme's and stuff unlikely to cause
conflicts).
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
>> How can you merge from unstable to trunk persons A changes when the unstable
>> branch contains persons A, B, C, D, E and F changes and each person may of
>> made multiple check ins at different (overlapping) times?
> You specify the revision number in the merge command.
And if they made multiple check ins you would need to specify each in turn?
So I think these are the steps involved (please correct if wrong this is off the top of my head).
1. Check out trunk and unstable vi svn co to make local copies (as you'll need two full copies of the SVN tree to make any changes)
2. Make changes in unstable.
3. Commit changes back to unstable via "svn ci". Note down all check in revision numbers.
4. Code is reviewed on list need a couple of fixes.
5. Make a few fixes/changes via more "svn ci" to unstable. Again note revision numbers.
6. Code is approved for trunk.
7. Make sure local copies of unstable and trunk is upto date via a "svn so" in both
8. Merge you local copy of unstable with you local copy of trunk. Do this by merging each changeset one by one via several "svn merge -c -XXX" using revision number above or find revision numbers by hunting though svn log.
9. Sort out any conflicts - hopefully none.
10. Check in changes to trunk via "svn ci"
Well actually that's not quite right as I think we've now lost the version history of changes in trunk (ie multiple check in unstable have become one check in in trunk). Any idea on how to get around this? It it possible to preserver history in some way?
Also lets go worse case and assume at step 9 there is conflicts (due to some other changes made in unstable that have not been merged into trunk as yet). To fix you would have to make extra changes to trunk not unstable, resolve and then check into trunk. But then unstable would be out of sync with trunk, so you would then have to merge unstable with trunk via "merge reintegerate" (I think but it getting rather confusing at this point) and then you would have to check in unstable.
Do we really need (or want) all this complexity?
Justin
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by Alex Harui <ah...@adobe.com>.
On 8/9/12 12:00 AM, "Omar Gonzalez" <om...@gmail.com> wrote:
>>
>>
>>> My ultimate first choice would be to get this project on Git. :)
>> Maybe I'm missing something, but my read of the article was that the
>> "develop" branch was the same as "unstable" and is even more restrictive
>> about checkins to trunk than I was thinking. It just seems to want to use
>> even more branching. How does that make things better?
>>
>>
> The "develop" branch is where things get integrated and stabilized. The
> "develop" branch also always has all of the latest fixes that are ready to
> be integrated into the next release.
>
> When its time for a release you make a "release" branch to make the changes
> to the source required for a new version, update version number, etc.
>
> While this "release" is being prepared development can continue in parallel
> for the next stuff.
Why is this better than just pulling selected changes? No need to lock down
if you know which changes you are going to take.
>
> This would happen by going to the "develop" branch and making a new
> "feature" branch. New stuff starts getting developed here.
I think our whiteboards can be feature branches, but again, why is it
required to use branches for everything?
>
> Now the release can be prepared while new features and fixes are being
> developed as well.
>
> When the "release" branch is ready to actually be released, version numbers
> updated etc, the release branch is tagged "v.1.1". Then the release branch
> is merged to "develop" to get it up to date w/ the release changes. Then
> the release branch is merged to "trunk/master" which triggers a Jenkins
> build and a new version of the product.
>
> When the "feature" branch is stable, it is ready for the next release, so
> it is merged back into the "develop" branch and stabilized. When all the
> "feature" branches have been merged back to "develop" and its ready for a
> new release you rinse and repeat the whole process.
>
> This approach works because it allows parallel development, off of
> baselines that are always easily found, because they're branched from
> either "develop" if its a new upcoming feature, or branched from a version
> tag if its a "hotfix" to an existing version.
>
>
> -omar
Will svn tagging work as well or was this description for Git?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by Omar Gonzalez <om...@gmail.com>.
>
>
> > My ultimate first choice would be to get this project on Git. :)
> Maybe I'm missing something, but my read of the article was that the
> "develop" branch was the same as "unstable" and is even more restrictive
> about checkins to trunk than I was thinking. It just seems to want to use
> even more branching. How does that make things better?
>
>
The "develop" branch is where things get integrated and stabilized. The
"develop" branch also always has all of the latest fixes that are ready to
be integrated into the next release.
When its time for a release you make a "release" branch to make the changes
to the source required for a new version, update version number, etc.
While this "release" is being prepared development can continue in parallel
for the next stuff.
This would happen by going to the "develop" branch and making a new
"feature" branch. New stuff starts getting developed here.
Now the release can be prepared while new features and fixes are being
developed as well.
When the "release" branch is ready to actually be released, version numbers
updated etc, the release branch is tagged "v.1.1". Then the release branch
is merged to "develop" to get it up to date w/ the release changes. Then
the release branch is merged to "trunk/master" which triggers a Jenkins
build and a new version of the product.
When the "feature" branch is stable, it is ready for the next release, so
it is merged back into the "develop" branch and stabilized. When all the
"feature" branches have been merged back to "develop" and its ready for a
new release you rinse and repeat the whole process.
This approach works because it allows parallel development, off of
baselines that are always easily found, because they're branched from
either "develop" if its a new upcoming feature, or branched from a version
tag if its a "hotfix" to an existing version.
-omar
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by Alex Harui <ah...@adobe.com>.
On 8/8/12 7:03 PM, "Omar Gonzalez" <om...@gmail.com> wrote:
> On Wed, Aug 8, 2012 at 7:00 PM, Justin Mclean <ju...@classsoftware.com>wrote:
>
>> Hi,
>>
>>> It would be more like option two, the always branch system. Features,
>>> fixes, releases, are always done off branches.
>> I would not be against that, I don't like the overhead and complexity it
>> brings compared to working in trunk, but it doesn't have the issues that a
>> single unstable branch does. So I assume you changed your mind re
>> supporting option 1?
>>
>> Thanks,
>> Justin
>
>
> I would say yes, this would be my first choice. I think it would help
> manage the amount of chaos that happens and will help maintain a clean
> trunk.
>
> My ultimate first choice would be to get this project on Git. :)
Maybe I'm missing something, but my read of the article was that the
"develop" branch was the same as "unstable" and is even more restrictive
about checkins to trunk than I was thinking. It just seems to want to use
even more branching. How does that make things better?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by Omar Gonzalez <om...@gmail.com>.
On Wed, Aug 8, 2012 at 7:00 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> > It would be more like option two, the always branch system. Features,
> > fixes, releases, are always done off branches.
> I would not be against that, I don't like the overhead and complexity it
> brings compared to working in trunk, but it doesn't have the issues that a
> single unstable branch does. So I assume you changed your mind re
> supporting option 1?
>
> Thanks,
> Justin
I would say yes, this would be my first choice. I think it would help
manage the amount of chaos that happens and will help maintain a clean
trunk.
My ultimate first choice would be to get this project on Git. :)
-omar
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> It would be more like option two, the always branch system. Features,
> fixes, releases, are always done off branches.
I would not be against that, I don't like the overhead and complexity it brings compared to working in trunk, but it doesn't have the issues that a single unstable branch does. So I assume you changed your mind re supporting option 1?
Thanks,
Justin
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by Omar Gonzalez <om...@gmail.com>.
On Wed, Aug 8, 2012 at 6:42 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> > This is an example of a good branching model:
> > http://nvie.com/posts/a-successful-git-branching-model/
>
> Yep and it uses multiple branches (ie equiv to option 3 in the SVN link I
> posted earlier) not a single branch as suggested we use for Flex.
>
> Justin
It would be more like option two, the always branch system. Features,
fixes, releases, are always done off branches.
-omar
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> This is an example of a good branching model:
> http://nvie.com/posts/a-successful-git-branching-model/
Yep and it uses multiple branches (ie equiv to option 3 in the SVN link I posted earlier) not a single branch as suggested we use for Flex.
Justin
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by Omar Gonzalez <om...@gmail.com>.
On Wed, Aug 8, 2012 at 3:50 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 8/8/12 3:19 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
> > No one has yet answered this:
> > How can you merge from unstable to trunk persons A changes when the
> unstable
> > branch contains persons A, B, C, D, E and F changes and each person may
> of
> > made multiple check ins at different (overlapping) times?
> >
This is an example of a good branching model:
http://nvie.com/posts/a-successful-git-branching-model/
While this article is about Git, the branches practices described in the
article can be applied to SVN. Because of the way the branches are set up
and used this should ensure that patches are always being made off of a tag
that is currently stable. The 'unstable' branch in this example is the
"dev" branch, which would be where new code is merged back in. Whenever
creating new feature or applying fixes than we can branch off of "dev" if
its for the next release, or off a version tag if its a bug fix for a
specific version. We can then move those fixes from version to version and
fix issues in each if they should arise, like say a fix in 3.5 is done one
way but because of arch changes in 4.0 the fix must be applied differently,
this branching model addresses that. I've used it successfully on a few
projects, but in Git, not SVN. But I believe it could work for SVN as well.
-omar
Re: Testing strategy (was: How to Merge Unstable Branch (was: [POLL]
Use Unstable Branch))
Posted by Omar Gonzalez <om...@gmail.com>.
On Wed, Aug 8, 2012 at 11:04 PM, Gordon Smith <go...@adobe.com> wrote:
> The solution for that is test-driven development. Apache doesn't have a QA
> team like Adobe. If developers write new stuff and don't write any tests,
> how are you ever going to trust anything new?
>
> Sent from my iPad
>
>
I would not be opposed to requiring that unit tests/mustella tests are
written for patches before they're considered for integration if we put out
the guidelines to developers on what is required of those tests. It would
make every committer's life easier if we had test suites that came w/
patches not only to ensure the quality of the code but to help to
understand what is going on in the mind of the developer that wrote the
patch.
-omar
Re: Testing strategy (was: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch))
Posted by Dave Fisher <da...@comcast.net>.
On Aug 9, 2012, at 8:10 AM, Greg Reddin wrote:
> On Thu, Aug 9, 2012 at 1:16 AM, Alex Harui <ah...@adobe.com> wrote:
>> Absolutely correct, but I don't want to hold off another release until we
>> have a mustella test for every code path and boundary condition, so I am
>> proposing using an "unstable" branch as the proving ground until we prove we
>> don't need it.
>
> Similar to my previous post, but maybe we avoid argument by simply
> flipping the model.
>
> Instead of stable trunk and unstable branch what about this?
>
> svn cp trunk branches/stable
>
> Trunk is now unstable and "branches/stable" is ready for a quick
> release. The only complication there is how to "promote" code from
> trunk to stable, but maybe we can do that on a case by case basis.
IMO the Release Vote is the main promotion process, but there might be other cases.
FYI - Some projects like Tomcat and HTTPD maintain multiple branches that are stable (or not so stable) releases.
Regards,
Dave
>
> Greg
Re: Testing strategy (was: How to Merge Unstable Branch (was: [POLL]
Use Unstable Branch))
Posted by Greg Reddin <gr...@gmail.com>.
On Thu, Aug 9, 2012 at 1:16 AM, Alex Harui <ah...@adobe.com> wrote:
> Absolutely correct, but I don't want to hold off another release until we
> have a mustella test for every code path and boundary condition, so I am
> proposing using an "unstable" branch as the proving ground until we prove we
> don't need it.
Similar to my previous post, but maybe we avoid argument by simply
flipping the model.
Instead of stable trunk and unstable branch what about this?
svn cp trunk branches/stable
Trunk is now unstable and "branches/stable" is ready for a quick
release. The only complication there is how to "promote" code from
trunk to stable, but maybe we can do that on a case by case basis.
Greg
Re: Testing strategy (was: How to Merge Unstable Branch (was:
[POLL] Use Unstable Branch))
Posted by Alex Harui <ah...@adobe.com>.
On 8/8/12 11:04 PM, "Gordon Smith" <go...@adobe.com> wrote:
> The solution for that is test-driven development. Apache doesn't have a QA
> team like Adobe. If developers write new stuff and don't write any tests, how
> are you ever going to trust anything new?
>
Absolutely correct, but I don't want to hold off another release until we
have a mustella test for every code path and boundary condition, so I am
proposing using an "unstable" branch as the proving ground until we prove we
don't need it.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Testing strategy (was: How to Merge Unstable Branch (was:
[POLL] Use Unstable Branch))
Posted by Gordon Smith <go...@adobe.com>.
The solution for that is test-driven development. Apache doesn't have a QA team like Adobe. If developers write new stuff and don't write any tests, how are you ever going to trust anything new?
Sent from my iPad
On Aug 8, 2012, at 10:11 PM, "Alex Harui" <ah...@adobe.com> wrote:
>
>
>
> On 8/8/12 10:00 PM, "Gordon Smith" <go...@adobe.com> wrote:
>
>> Why all the focus on branching strategies? It makes more sense to focus on a
>> testing strategy. We need an 'ant tests' and a requirement that it pass for
>> all changes to trunk.
>>
>> Didn't the mustella tests get submitted? What more do we need other than an
>> easy way to run them?
>>
> Because I don't have faith that Mustella catches everything, and I'd rather
> merge stuff we feel good about rather than try to remove stuff we don't feel
> good about when were trying to get a release out.
>
> You know as well as I do what the bug curve looked like for most things
> after they landed.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
Re: Testing strategy (was: How to Merge Unstable Branch (was:
[POLL] Use Unstable Branch))
Posted by Alex Harui <ah...@adobe.com>.
On 8/8/12 10:00 PM, "Gordon Smith" <go...@adobe.com> wrote:
> Why all the focus on branching strategies? It makes more sense to focus on a
> testing strategy. We need an 'ant tests' and a requirement that it pass for
> all changes to trunk.
>
> Didn't the mustella tests get submitted? What more do we need other than an
> easy way to run them?
>
Because I don't have faith that Mustella catches everything, and I'd rather
merge stuff we feel good about rather than try to remove stuff we don't feel
good about when were trying to get a release out.
You know as well as I do what the bug curve looked like for most things
after they landed.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Testing strategy (was: How to Merge Unstable Branch (was: [POLL]
Use Unstable Branch))
Posted by Gordon Smith <go...@adobe.com>.
Why all the focus on branching strategies? It makes more sense to focus on a testing strategy. We need an 'ant tests' and a requirement that it pass for all changes to trunk.
Didn't the mustella tests get submitted? What more do we need other than an easy way to run them?
- Gordon
Sent from my iPad
On Aug 8, 2012, at 7:21 PM, "Om" <bi...@gmail.com> wrote:
> On Wed, Aug 8, 2012 at 6:40 PM, Justin Mclean <ju...@classsoftware.com>wrote:
>
>> Hi,
>>
>>> I would use the name "alt-trunk" instead of "unstable" for the other
>>> branch. Every rule that applies to trunk would apply to the alt-trunk
>>> branch.
>> The issue I see is having one single branch not the name. You would be
>> fine with the multi step step check in process (with unresolved issues) as
>> describe below every time you wanted to make a change?
>>
>>
> If we cannot guarantee that the branch is stable everytime anyone wants to
> make a change, how can we do it in trunk? What special properties that
> trunk have that makes it easier there?
>
> If I check in something that breaks the build or causes numerous issues
> into alt-trunk, I will have to either pull it out or fix it in alt-trunk
> itself. Trunk does not even come into picture here.
>
> Only when we are closer to a release, we will merge alt-trunk into trunk.
> It would be a much smoother process then because we would have brought
> alt-trunk to stability before we attempt the merge into trunk.
>
>
>>> Remember that if we do all the development in trunk, we would have
>>> to do the same thing except that it would be a much bigger problem
>> because
>>> we dont have any place to go when we screw things up.
>> How about svn revert?
>>
>
> That is the command we would use, yes. But what if we dont find out the
> issues in time? What if we find out multiple huge issues when it is time
> to cut a release. The complexity that would ensue is something we are not
> set up for now.
> Maybe after a couple of releases, yes.
>
>> When are happy with alt-trunk's state, we merge alt-trunk into trunk and
>> cut a release off of trunk.
>
>> So we would have to have a code freeze while we sort out merge issues and
>> the like?
>
>
> Yes.
>
>
>> How would you not include the changes you did not want to go into trunk?
>>
>> How would we do it if everyone checks into trunk directly?
>
>
>
>> Just want to make it clear what people are agreeing to.
>>
>>
> Let's use alt-trunk as a training ground. Lets get it right there and we
> can move to working directly off of trunk.
>
> Om
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by Om <bi...@gmail.com>.
On Wed, Aug 8, 2012 at 6:40 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> > I would use the name "alt-trunk" instead of "unstable" for the other
> > branch. Every rule that applies to trunk would apply to the alt-trunk
> > branch.
> The issue I see is having one single branch not the name. You would be
> fine with the multi step step check in process (with unresolved issues) as
> describe below every time you wanted to make a change?
>
>
If we cannot guarantee that the branch is stable everytime anyone wants to
make a change, how can we do it in trunk? What special properties that
trunk have that makes it easier there?
If I check in something that breaks the build or causes numerous issues
into alt-trunk, I will have to either pull it out or fix it in alt-trunk
itself. Trunk does not even come into picture here.
Only when we are closer to a release, we will merge alt-trunk into trunk.
It would be a much smoother process then because we would have brought
alt-trunk to stability before we attempt the merge into trunk.
> > Remember that if we do all the development in trunk, we would have
> > to do the same thing except that it would be a much bigger problem
> because
> > we dont have any place to go when we screw things up.
> How about svn revert?
>
That is the command we would use, yes. But what if we dont find out the
issues in time? What if we find out multiple huge issues when it is time
to cut a release. The complexity that would ensue is something we are not
set up for now.
Maybe after a couple of releases, yes.
> When are happy with alt-trunk's state, we merge alt-trunk into trunk and
> cut a release off of trunk.
> So we would have to have a code freeze while we sort out merge issues and
> the like?
Yes.
> How would you not include the changes you did not want to go into trunk?
>
> How would we do it if everyone checks into trunk directly?
> Just want to make it clear what people are agreeing to.
>
>
Let's use alt-trunk as a training ground. Lets get it right there and we
can move to working directly off of trunk.
Om
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I would use the name "alt-trunk" instead of "unstable" for the other
> branch. Every rule that applies to trunk would apply to the alt-trunk
> branch.
The issue I see is having one single branch not the name. You would be fine with the multi step step check in process (with unresolved issues) as describe below every time you wanted to make a change?
> Remember that if we do all the development in trunk, we would have
> to do the same thing except that it would be a much bigger problem because
> we dont have any place to go when we screw things up.
How about svn revert?
> When are happy with alt-trunk's state, we merge alt-trunk into trunk and
> cut a release off of trunk.
So we would have to have a code freeze while we sort out merge issues and the like? How would you not include the changes you did not want to go into trunk?
Just want to make it clear what people are agreeing to.
Thanks,
Justin
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by Om <bi...@gmail.com>.
Right now, very few people in this list have an idea of how complicated
the Flex codebase in trunk is. We dont even know how to run a single test
if we make a change a simple component. As a group, we are not ready to
start throwing code into trunk.
I would use the name "alt-trunk" instead of "unstable" for the other
branch. Every rule that applies to trunk would apply to the alt-trunk
branch.
Let us keep keep trunk protected for a while till we figure out how to keep
"alt-trunk" stable at all times. When it is release time, we test if
alt-trunk is stable. If not, we fix it till we are happy. If we cannot
fix it, we identify the committer and ask them to remove the offending
parts. Remember that if we do all the development in trunk, we would have
to do the same thing except that it would be a much bigger problem because
we dont have any place to go when we screw things up.
When are happy with alt-trunk's state, we merge alt-trunk into trunk and
cut a release off of trunk.
Eventually we will become good at keeping 'alt-trunk' stable. At that
point, we can get rid of that branch and do all the development in trunk.
Thanks,
Om
On Wed, Aug 8, 2012 at 5:36 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> > For those using eclipse, has anyone ever tried CollabNet eclipse plugin?
> > It's from the same guys that created subclipse. Their interface makes all
> > this merge process smoother and can even prevent you from merging if you
> > don't follow SVN best practices.
> If we go with a single unstable branch we are not following SVN best
> practices so no idea how/if this tool would work but if it makes merging
> easier certainly worth taking a look at.
>
> Thanks,
> Justin
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> For those using eclipse, has anyone ever tried CollabNet eclipse plugin?
> It's from the same guys that created subclipse. Their interface makes all
> this merge process smoother and can even prevent you from merging if you
> don't follow SVN best practices.
If we go with a single unstable branch we are not following SVN best practices so no idea how/if this tool would work but if it makes merging easier certainly worth taking a look at.
Thanks,
Justin
Re: How to Merge Unstable Branch (was: [POLL] Use Unstable Branch)
Posted by João Fernandes <jo...@gmail.com>.
For those using eclipse, has anyone ever tried CollabNet eclipse plugin?
It's from the same guys that created subclipse. Their interface makes all
this merge process smoother and can even prevent you from merging if you
don't follow SVN best practices. Regarding merging between different
branches, it allows to pick which which commit you plan to merge if you
don't want to merge all.
João Fernandes