Re: With feature branches, what is ever committed directly to master
- From
Jon Seymour <jon.seymour@gmail.com>
- Date
- Aug 13, 2010, 23:52 UTC
- Message-ID
- <AANLkTimD34VqsMJzUyTawBbdKoXZNXbcTUxLwk5Rj_S3@mail.gmail.com>
- In-Reply-To
- <m2ocd6yx3h.fsf@Spindle.sehlabs.com>
On Sat, Aug 14, 2010 at 8:19 AM, Steven E. Harris <seh@panix.com> wrote:
Show 10 quoted lines
> Jon Seymour <jon.seymour@gmail.com> writes: > >> Otherwise, I keep them clean and merge them into the base of my >> working branch (as described into an earlier note). By always merging >> into the base of my working branch (and never the tip) I can keep my >> working tree stable and my patches clean. > > Can you clarify what you mean by "merging into the base" and "never the > tip"? Perhaps a pointer to the earlier note you mentioned would suffice. >
Here is a link to the earlier note:
http://permalink.gmane.org/gmane.comp.version-control.git/153168
this explains how I am using the term base.
Informally, it is the first commit your history which contains work that your current work depends on, but is not part of your current work. It is always directly reachable from your head via a path which does not include a merge (and, as such, defines a linear range of commits that is easily re-ordered or rebased as required).
The idea is that the base of your working branch accumulates dependencies, while the head (or tip) of your working branch accumulates your work. By merging at the base, you are never "hiding" work in progress with a merge. As your view of what your dependencies are changes, you can rebuild your base at will, and then rebase your work on top of that.
jon.
Show 8 quoted lines
> -- > Steven E. Harris > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >