0

So for my first webapp I tried to develop all or a lot of the components at once and have succeeded implementing things I didn't think were possible. However, during the deploy process, I need to start releasing these little by little and thus a lot of code that I have committed to master shouldn't really be there until a later date. I would need to remove it for now, and add it in back later.

How can I trim my codebase so that it only has the code I need for now, and keep all that committed code somewhere I go back and add it in with a git merge later? (Instead of having the git merge delete those things I deleted from master)

I will probably need to do this multiple times.

(Probably shouldn't have done it this way, but shit happens when you learn to develop by yourself without guidance.)

ovatsug25
  • 7,786
  • 7
  • 34
  • 48
  • Is it certain commits that you need to remove or is the needed and the unneeded code mixed in the same commits? – ellak Mar 04 '13 at 14:09
  • You'll want to take a look at the [`gitworkflows(7)`](http://git-scm.com/docs/gitworkflows) man-page, and perhaps also at [this famous blog-post](http://nvie.com/posts/a-successful-git-branching-model/) to learn more on the best practices when using Git. If you decide to follow the latter approach, there's a Git extension called [`git-flow`](https://github.com/nvie/gitflow) providing you with commands that help you implementing it. – Michael Wild Mar 04 '13 at 14:36
  • @ellak - unfortunatley, they're mixed in the same commit - yeah, i did that... :( – ovatsug25 Mar 04 '13 at 14:42
  • Check this answer for how to break a commit into multiple commits http://stackoverflow.com/a/6217314/1599890 – ellak Mar 05 '13 at 12:15

2 Answers2

2

you can checkout a commit, by doing

git checkout hash

where hash is a hash string shown by git log. Once you're finished, use 

git checkout master

In general, you should have a stable branch, into which you merge features for release.

hannes
  • 966
  • 9
  • 13
1

Option 1: Choose versions by hand

(as per hannes' answer). The downside of this is that there's no record in git afterwards, of which commits were released

Option 2: Tag versions

Tagging releases is good practise anyway!

Same as option 1 but you tag the checked-out commit with git tag -am'first release' v1.0 (or whatever). This way, you have a record of which commits were released.

Option 3: Fake release history

You can create a release branch from your first commit, and then use git merge --no-ff to merge each blessed commit (as per options 1 & 2) onto the release branch. I'd still tag them, but this provides something like a fake development history. If no-one else has cloned your repo, you can reset master to your complete release branch at the end, if you want the structure but not the separate branch.

Useless
  • 64,155
  • 6
  • 88
  • 132