1

This is probably a duplicate, but after going through the GitHub help page about creating releases, and going through many posts on SO, I haven't found what I am looking for.

I have worked with git for a while, and I often find myself in a situation where parts of the contents in master are ready to be shared, but others still need to be refined, further tested or refactored. I can create a new branch and remove what I don't want to release just yet, but that still preserves their history, and for the next version, I won't be able to simply merge improvements along with a subset of new contents without starting over essentially with a brand new branch every time.

What I really would like to do is select folders and files which are ready to be released, filter relevant history for these files only, and rebase any content which is not in the release on top of this new history. I realise that this is a form of "rewriting history", but is there any way to do this with git? And if not, what is the "proper" way of creating releases with a relevant history and which can be merged upon later on?

Stevoisiak
  • 23,794
  • 27
  • 122
  • 225
Jonathan H
  • 7,591
  • 5
  • 47
  • 80
  • 1
    "creating releases with a relevant history and which can be merged upon later on". That's practically the definition of a branch. I don't understand your concern with branching for every release. – Matt S Mar 04 '17 at 15:51
  • Can I ask why you don't want the history of the unreleased pieces in the release branch? – oyvind Mar 05 '17 at 19:32
  • @oyvind I think you and Matt are right in the sense that it doesn't make any practical difference, but I would find it cleaner and I think the history would also be easier to manage/store if there was a way to trim anything extraneous to a subset of specified files, and rebase unselected contents on top of this new history. It would also make it clearer when looking back at the tag of a specific release. – Jonathan H Mar 05 '17 at 19:40

2 Answers2

1

The easiest solution would probably keep a separate release branch containing the files you want public, then selectively merge in the files you want changed from master. This way, only the specific files you want changed actually get updated.

Community
  • 1
  • 1
Stevoisiak
  • 23,794
  • 27
  • 122
  • 225
1

Try git filter-branch with the subdirectory-filter and prune-empty switches. Make sure you know what you are doing since it is a very invasive command. Read the whole man page https://git-scm.com/docs/git-filter-branch.

As far as rebasing the rest of the history on top, I think the number of conflicts would be entirely prohibitive, unless your history is exceptionally short. Also if you are talking about rebasing the main development branch, it would cause trouble when the developers pull the new version into their respective local clones.

oyvind
  • 1,429
  • 3
  • 14
  • 24
  • 1
    Thanks, I guess cherry-picking into a new branch (as suggested in Steven's answer below) might be the best and most conventional way of creating releases. The last diagram in [this post](http://stackoverflow.com/a/5968622/472610) shows a typical project development with git, I wish it was this orderly in practice, or maybe I'm just bad at making linear progress. :) – Jonathan H Mar 05 '17 at 19:54
  • I'm not sure excluding files in the release branch is common. If you could say a bit more about how these partial releases would look, I could help a bit more. Maybe, if you're releasing parts independently, you would be better off with separate repos, or separate release branches for each part, where you wouldn't need to exclude files because for each branch you would know what was to be released from it. A lot can be solved by release scripts :-). – oyvind Mar 05 '17 at 20:04