git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Leam Hall <leamhall@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Branch Management questions
Date: Thu, 15 Oct 2020 15:57:54 -0400	[thread overview]
Message-ID: <20201015195754.GD1490964@coredump.intra.peff.net> (raw)
In-Reply-To: <595540a9-0000-8dcd-c555-3168d1b2d066@gmail.com>

On Thu, Oct 15, 2020 at 05:51:39AM -0400, Leam Hall wrote:

> 1. Two developers.
>   Dev A is working on Branch A, off a release_candidate branch.
>   Dev B is working on Branch B, off the same release_candidate branch.
>   Branches usually run 1-4 weeks.
>   Dev A does some work that would help Branch B.
>   How does Dev A get the Branch B work that is needed, in a
>     way that does not confuse the merge process at the end
>     of the release cycle?

If Dev A is OK getting _all_ of branch B, the best thing is to simply:

  git checkout branch-a
  git merge branch-b

That goes from:

  old -- a1 -- a2 -- a3   <-- branch-A
     \
      b1 -- b2 -- b3       <-- branch-B

to: 

  old -- a1 -- a2 -- a3 -- M  <-- branch-A
     \                    /
      b1 -- b2 -- b3 ----+    <-- branch-B

and then later when they merge again (either separately, or into
release_candidate), Git knows that "M" is the merge-base instead of
"old":

  old -- a1 -- a2 -- a3 -- M -- a4 -- a5 -- a6 <-- branch-A
     \                    /
      b1 -- b2 -- b3 ----+-- b4 -- b5 -- b6    <-- branch-B

If you need just parts of the work on b, then you'd probably have to
cherry-pick them. They should usually merge together cleanly eventually,
but if you further modify them (or touch nearby areas), that may result
in a conflict on merge into release_candidate.

> 2. One developer.
>   Working on Branch P, realizes that a new functionality X is
>     needed.
>   X isn't specific to Branch P, but critical to it.
>   What is the best way to deal with X, knowing that further work
>     on X will need to be done?

Create a new branch X for the shared topic, and base it not on P but on
whatever the fork point of P is (i.e., your release_candidate or
whatever). Then do some work on X, and merge X into P as needed.
Likewise for any other branch that builds on X.

If you've already built part of X on top of P, then you could
cherry-pick those parts onto the new branch X, and then either:

  - rebase P on top of X (which will drop the redundant bits)

  - merge X into P. You may have to resolve conflicts around the
    redundant parts, and you'll have some redundant commits left in the
    history (but the new merge will become the base for further merges
    between the branches)

-Peff

      parent reply	other threads:[~2020-10-15 19:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15  9:51 Branch Management questions Leam Hall
2020-10-15  9:55 ` Konstantin Tokarev
2020-10-15 10:30   ` Leam Hall
2020-10-15 10:39     ` Konstantin Tokarev
2020-10-15 19:57 ` Jeff King [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201015195754.GD1490964@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=leamhall@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).