[Gambas-devel] Gambas to Git(Lab)

[Adrien Prokopowicz]

Le Sun, 23 Jul 2017 01:33:09 +0200, Benoît Minisini via Gambas-devel  
<gambas-devel at lists.sourceforge.net> a écrit:
>
> The problem I encountered when moving from subversion to git in my job  
> is that git does not really have tags and branches that behave the same  
> way. I.e. being actual independent trees.
>
> A recently added feature named "working tree" in git seems to help to do  
> the same thing: developing on different versions at the same time.
>
> Or maybe I didn't understand how to use git for that?
>
> Regards,
>

You can work on different versions/branches at the same time. It's just  
that branches
in Git are waay different from SVN branches. :)

In SVN, both branches and tags do not really exist : they are just separate
directories, and creating a new branch/tag essentially means copying the  
entire
directory over, from /trunk to /branches/3.10 for example.
(SVN actually uses some Copy-on-Write mechanisms under the hood, such as  
hard-links,
but from the user point of view it is just a regular copy).

In Git however, branches are more of a diverged history : they share the  
same history
up to the point where you create the branch, but then the commits you make  
in each
branch are completely separate.
For example, you create a new 3.10 branch from the master (main) branch.  
The commits
you add to the 3.10 branch will not be applied to the master branch, and  
if you switch
back to master, you are in the same state you were before creating the  
branch, and from
there you can add some commits to master (which will not affect 3.10).

You can check out the Git documentation about branches here [0]. It has  
diagrams
and all the commands needed to work with branches. But if you (in the  
broad sense, not
just Benoît) have questions, you can just ask me. :)

What I really like about workflows based on Git branches, is that they  
make it really
easy to start working on new (and unfinished) features without submitting  
them
to the main branch. You simply create a new branch and start working in  
it, allowing
everyone to see your work and provide feedback, without having to include  
it in the
next release.
And when your work is ready, you just merge it back into the main branch.  
:)

A recent example of this would be the gb.term.form component : Fabien  
started working
on it at the time of Gambas 3.9, but just said it is not ready for 3.10.  
If the unfinished
component is in its own branch, then you can just release what is on the  
main branch
without worrying. (This kind of workflow is also explained in the Git  
documentation,
see here[1]).

What makes this workflow even more awesome is the fact than anybody (on  
GitLab/GitHub)
can fork the Gambas repository (i.e. copy the repository into a new one  
they own),
make changes in their repository, and then ask to merge the changes  
through a
Merge Request[2] (GitHub calls these Pull Requests). You can then review  
their
changes, approve them (or not), and merge them.
This is great for allowing one-time contributors to participate without  
having to
give them full permissions on the repository (and it's much better than  
sending
a patch for review). :)

(… and here I made a hundred-page-long message again. Sorry about that,  
but Git
is exciting !)

Regards,

[0]  
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
[1] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
[2] https://docs.gitlab.com/ee/user/project/merge_requests/index.html

-- 
Adrien Prokopowicz