On 2016-07-19, at 11:02 PM, Charles Manning wrote:
> Squashing makes sense if you have a really ratty bunch of checkins with
> work-in-progress checkins etc., but unless it's a trivial topic branch I
> would still typically make the final set of commits into a few logical steps.
>
> It costs
Squashing makes sense if you have a really ratty bunch of checkins with
work-in-progress checkins etc., but unless it's a trivial topic branch I
would still typically make the final set of commits into a few logical
steps.
It costs pretty much nothing to leave old topic branches around (but a few
Hello,
that, again, depends on your workflow. For one project, I
interactive-rebase my feature branches often, and merge them into master
when they are finished; after that, they can live forever in the repo, and
if the feature needs a fix or change, I can check them out. For another
project, I sq
So I'm trying to make sure I'm seeing everything that I got in a fetch.
My first attempt to fetch was:
keybounceMBP:Finite-Fluids michael$ git fetch
https://github.com/Draco18s/Finite-Fluids.git master
remote: Counting objects: 12, done.
remote: Compressing objects: 100% (4/4), done.
remote: Tot
Lets say I've got a topic branch. I've made a bunch of commits. It's messy. But
it's done.
As I understand it, best practice is to do a squash commit of the whole thing
onto the parent branch (develop or master, depending on workflow). And I can do
that.
What do I do with the leftover? I thoug