How to clean up my git repositories

Question

I have been lazy and putting all my commits into the master branch. What I want to do now is to structure my git repositories like this guide says: http://nvie.com/posts/a-successful-git-branching-model/

What I want to do now is to move all my commits in master to a new branch called master-cleanup. Then I will want to merge master-cleanup with master so that I only have one commit in master. The reason for why I want to do this is that all the commits in master takes up a lot of space and if I move all commits to a cleanup branch I guess that I can on my local machine remove that branch and only have it located on the server. This way when I checkout my master branch I will only download the latest commit and not all the history right?

I tried to do this with first creating the new branch and then reset the master to the first commit. After that I merge with master-cleanup with no-ff:

git branch master-cleanup
git reset --hard 4f8d90cc225288bf889090f80103cfa0887a4742
git merge --no-ff master-cleanup

I thought that this would move all my commits to the new master-cleanup branch but when I perform the merge I also import all the commits. I thought that the --no-ff would prevent this and force the merge to be a new single commit to the master? Now I git the entire commit log plus the new merge commit...

Any ideas on how to solve what I want to do?

Balog Pal · Accepted Answer · 2013-06-27T08:56:07.057

1

--no-ff means no fast forward. It ensures that you get a 2-parent merge commit even if the merged branch directly follows your top. Without you'd just get a linear history without a hint that the merged bunch of commits belong together.

To meld commits into one you use merge -- squash or if already there, you can use rebase -i and ask squash. Or reset --soft a lower point, and commit the index.

As for the other part of question, history indeed takes up some space but it rarely worth mentioning in size for sources. And if you are just not interested in working with the past, leave the repo alone as it is. Just make a shallow clone of it. Read up on git clone --depth 1. Even if you don't use it for practice, you can make such a clone to see the size difference and decide it not worth fiddling.

edited Jun 27 '13 at 08:56

answered Jun 27 '13 at 08:39

Balog Pal

16,195
2
23
37

--squash seems to do what I want but I'm not sure if I want to do this anymore :) My repo is quite large because I have a lot of media in my project (movies, pdf etc) so whenever one media item changes I have a history of all the versions so the git repo groves fast. If I would start from scratch and work like it is descibed in the link with a master, development and feature branches. Would the master branch contain a log of all commits, even those that originated in the feature branch? So the master brash would actually be just a big anyway? – Magnus O. Jun 27 '13 at 12:04
So if I would want to keep the master branch and development branch small I would always have to merge with the --squash and not the --no-ff flag? Any downsides of working like this? I see no real use of having all the history of the feature branches in the development and master branch? I will always keep the feature branches at the server for history if I would want to go back. – Magnus O. Jun 27 '13 at 12:06
squash-merging features is considered fair game, especially if you define feature at good granularity (AKA small). Depending on how media files are used in the project it might be better to keep them in a different repo, maybe linked as submodule – Balog Pal Jun 27 '13 at 12:12

score 0 · Answer 2 · edited May 23 '17 at 10:32

0

You need to specify --squash for git merge. See this and this answer for more info.

edited May 23 '17 at 10:32

Community

1
1

answered Jun 27 '13 at 08:06

thSoft

21,755
5
88
103

score 0 · Answer 3 · answered Jun 27 '13 at 08:38

There is no need to create a new branch. There are a lot of ways to do this. Let me get this straight first. You want to merge all you commits into one commit. This is your problem right.

Try these commands

git log --oneline //Show all your commits. (Note down the SHA of your first commit)
git rebase --interactive 22dacee where 22dacee is the SHA you noted in above step.

Now, an editor will popup and will show you something like this

pick aasad23 X
pick a434fsa Y
... a long list follows.

# Rebase adrtec..ds3452 onto adrtec
#
# Commands:
#  p, pick = use commit
#  r, reword = use commit, but edit the commit message
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#  f, fixup = like "squash", but discard this commit's log message
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.

Now, just replace all pick words with s except for the first one. And save the file. New editor will popup again and will show you which of the commits are going to be merged. Just recheck it once and save it again. You will see there will be only one commit now.

How to clean up my git repositories

3 Answers3