git and C++ workflow, how to handle object and arc

问题:

I use git to interface with an SVN repository. I have several git branches for the different projects I work on.

Now, whenever I switch from one branch to another using 'git checkout ', all the compiled executables and object files from the previous branch are still there. What I would like to see is that switching from branch A to B results in a tree with all object files and binaries from the last time I worked on branch B.

Is there a way to handle this without creating multiple git repositories?

Update: I understand that executables and binaries should not end up in the repository. I'm a bit disappointed in the fact that all the branching stuff in git is useless to me, as it turns out I'll have to clone my proxy git repository for every branch I want to start. Something I already did for SVN and hoped to avoid with git. Of course, I don't have to do it, but it would result in me doing a new make most of the time after switching between branches (not fun).

回答1:

What you want is a full context, not just the branch... which is generally out of scope for a version control tool. The best way to do that is to use multiple repositories.

Don't worry about the inefficiency of that though... Make your second repository a clone of the first. Git will automatically use links to avoid having multiple copies on disk.

Here's a hack to give you want you want

Since you have separate obj directories, you could modify your Makefiles to make the base location dynamic using something like this:

OBJBASE = `git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1\//'`
OBJDIR = "$(OBJBASE).obj"
# branch master: OBJBASE == "master/", OBJDIR == "master/.obj"
# non-git checkout: OBJBASE == "", OBJDIR == ".obj"

That will but your branch name into OBJBASE, which you can use to build your actual objdir location from. I'll leave it to you to modify it to fit your environment and make it friendly to non-git users of your Makefiles.

回答2:

This is not git or svn specific - you should have your compiler and other tools direct the output of intermediate files like .o files to directories that are not under version control.

回答3:

To keep multiple checkouts of the same repo, you can use git --work-tree. For example,

mkdir $BRANCH.d
GIT_INDEX_FILE=$BRANCH.index git --work-tree $BRANCH.d checkout $BRANCH

回答4:

You could set your IDE compiler to generate all private temporary files (.class and so on) in <output>\branchName\....

By configuration your compilation setting branch by branch, you can register the name of the branch in the output directory path.

That way, even if though private files remain when you git checkout, your project on the new branch is ready to go.

回答5:

In the contrib/ directory of the git distribution, there is a script called git-new-workdir that allows you to checkout multiples branches in different directories without cloning your repository.

回答6:

Those files aren't tracked by Git or Subversion, so they're left alone on the assumption that they are of some use to you.

I just do my checkouts in different directories. Saves me the trouble of doing cleanup.

回答7:

A make clean should not be necessary because files that are different between different branches get checked out with the actual date!!!

This means that if your Makefile is correct, only those object-files, libs and executables are compiled again that really changed because of the checkout. Which is exactly the reason a makefile is there in the first place.

The exception is if you need to switch compiler options or even compilers in different branches. In that case probably git-new-workdir is the best solution.

回答8:

If the compiled executables are files that have been checked in
then git stash solves the problem.

[compile]
git stash save "first branch"
git checkout other_branch
[Fiddle with your code]
[compile]
git stash save "second branch"
git checkout first_branch
git stash apply [whatever index your "first branch" stash has]
# alternatively git stash pop [whatever index...]

If the compiled executables are files that have not and will not be checked in
then simply add them to .gitignore