On Mon, May 23, 2016 at 04:24:38PM +0200, Florence Blanc-Renaud wrote:
> 
> - I start working on a specific issue and decide to create a branch on my
> git repository (on my laptop)
> git clone git://git.fedorahosted.org/git/freeipa.git
> git branch -b issue

This likely needs to be

     git checkout -b issue

> - When the tests are ok and I want to submit a patch, can I stay on the
> branch "issue" to create the patch or should I merge first with the main
> branch? If a merge is required, is it recommended to pull then merge or
> merge then pull?

As mentioned by Martin, you are looking for rebase, not merge. Rebase
will re-create commits from the branch on top of other branch (master,
most likely), omitting changes that got to master in the mean time,
and giving you chance to resolve conflicts with whatever other changes
might have gone to master, so that others have as clean experience as
possible.

If you look at FreeIPA's history (I like gitk for that), you will see
that merge commits are very rarely used. The reason for keeping the
history linear (and thus rebasing on master often) is that it forces
the author to be explicit about the diffs, plus git tools for
introspecting history often choke on parallel branches that get
merged.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to