问题
I'm building my own rpm's. Usually I use git archive to get a tarball from the commit or tag I'm interested in (suppose I have put a tag 1.0):
git archive --format=tgz --prefix=product-1.0 1.0 > product-1.0.tgz
suppose now I am doing some local developments that I haven't committed yet and I want to get an archive; is there any way to obtain this without having to commit?
edit I could just use something like this:
tar cf product-1.0.tgz --exclude=.git
but that will include all binaries and other untracked files which I prefer not...
回答1:
I'm not 100% sure this is exactly what you want, but you can stash the changes you've made with git stash create, which will give you a hash for the current state of the repo - and then create an archive for it with git archive <options> $HASH.
回答2:
git ls-files | tar Tzcf - archive.tgz
回答3:
Sorry, that will not be actual answer.
There may be some way, but actually I don't see much point to it. Committing is rather light. There's nothign wrong in committing a completely temporary or broken files. Until you push it to public, it's all your local storage. Just create a new branch, commit to it, then at some point of time you can delete that branch, even immediatelly. The only thing you must be careful is to not push that branch to public repo. The biggest plus in it is that, during commit, you will be able to selectively pick what files you want to include. It will allow you to filter out any unwanted binaries, archives, etc - and at very fine details. It's really much more usable than trying to filter them by bash and similar.
So, for me, if you are building packages, then you really want to commit. Just because at some point of time in future you will need to check what were the original files. Or revert to it. That's exactly what branches and whole repository is: marking and remembering some files in some state. Repository is not just for keeping "release code". It is for keeping everything relevant that you needed at any point of time, in the same exact state as it was back then.
Therefore, I'd even recommend true branching for those builds/packagings. Not stash. Stash is something temporary, meant to evaporate quickly. You get a hash for that, but you can very easily delete that whole branch/stash/revision. That would exactly annihilate the essence of versioning. You will put it into git, just to delete it.
With use of normal branches and normal commits, at any future time you will be able to review or recreate any RPM you have built at any time in the history. IMHO, that's huge plus.
回答4:
Create a branch called archive, add, and commit the files I want to track in addition to what is already tracked in git. Whether its your currently untracked development files, generated documentation, binaries you're not tracking in Git but want archive, etc.
With those committed locally, you can now use
git archive archive --format=tgz --prefix=product-1.0 1.0 > product-1.0.tgz
Note, the first archive is the command, the second is the branch name.
Now revert that last commit so those files become untracked again
git reset --soft HEAD~; git reset
Switch back to master and delete the archive branch.
回答5:
When you have unstaged changes you can try git diff and tar or zip commands.
tar command:
git diff --name-only -a | tar Tzcf - myUnstagedChanges.tgz
zip command:
git diff --name-only -a | xargs zip myUnstagedChanges.zip
Furthermore if you need to do this about a commit, try git show [idCommit] command.
git show --pretty="" 9471ae --name-only -a | tar Tzcf - myCommitedChanges.tgz
or
git show --pretty="" 9471ae --name-only -a | xargs zip myCommitedChanges.zip
The compress archive will be created into git root directory.
Hope I've helped.
回答6:
The following command with help
git archive --output=modified-files.zip HEAD $(git ls-files --modified)
来源：https://stackoverflow.com/questions/23115777/git-archive-with-unstaged-changes