Working on a Git feature branch and use(?) branch at the same time

I'm new to Git, and sometimes I find myself working on a feature branch(say ad开发者_运维百科ding library A) while also working on program B that uses it(which I call the use branch, maybe there is a better word). So what I've done in the past is have two separate branches, work on the feature branch 'til it seems like it might work, then start using the API in the use branch, merge the feature branch in and see if it works. If it doesn't work, I go back to the feature branch, fix the issue, merge and repeat. Is this the best way to do this?

My goal is to keep the feature branch separate from any implementation that uses it(though I suppose even that is up for debate). What I also thought of later is presuming I'm editing a limited number of files I could just do the 'fixing' changes in the use branch and use 'git checkout' in the feature branch to bring just the library changes back in.

What I guess I really want is to be working in a single workspace, but specify that these files belong to branch A and these files belong to branch B and be able to commit them separately. (I can imagine an implementation where you specify 2(or n) branches to combine into a pseudo branch, presuming that you don't alter the same files. Then when you change files that are in one branch you can commit just those files to that branch(and if you modify new files, you have to specify which branch this file 'belongs' to)). For all I know this may be in opposition to how Git works, but I don't know it enough to tell. :)

Thoughts?

Clarifications/Addendums:

Example(not actually what I'm doing :)): I'm writing a program to generate a random number and then write it to a file. So my main program is in its own branch(what I refer to as my 'use' branch). My main program is simply:

MyFileApi::Write("myfile", random());

where random() is some system API that already exists, but MyFileApi::Write is a new feature I'm developing(so my program is using this new feature). In my 'feature branch' I have say a header file and implementation for MyFileApi::Write. So I've written some implementation of MyFileApi::Write, but I want to test it using my new random-number-file-writer program(it would probably be best to write tests specifically for this API, but I'm being lazy and testing it in my program that uses the code). So what I've been doing is merging in my MyFileApi::Write changes into my 'use' branch, testing it, seeing it fail, going back to my feature branch, fixing the issue, merging again, repeat etc...

There is nothing preventing you from cloning the repository twice, so you have two local workspaces, one for each branch. If the build output from the feature branch needs to be in the use branch, you can always use symlinks (assuming you are on a Unixy OS) and .gitignore them from the use branch.

However, if these are two different programs (and it sounds like they are) then they should not be on separate branches at all -- they should either be in the same directory tree in both branches, or they should be in separate repositories altogether. It's not considered good style to have one branch exclusively for one program and one branch exclusively for another (unless they are release branches or something special like that).

I'm no git guru, but you can theoretically have as many branches as you want. What I would suggest, assuming you have library A in its own git repo and program B (which uses A) in its own git repo would be:

• create a branch (for example, "new_features") in A
• modify your code, try to compile/link, fix errors
• create a branch (use the same name to show what will be tested - "new_features") in B
• modify code in B to use the new/modified features that you added/changed in A
• compile/link/test B

You really need to have the branch in your program B if the changes you are making to library A change its exposed set of functions/variables. If all you are doing is making changes to the "background" code (that is, leave the exposed functions/vars as they are while improving algorithms, memory usage, etc in those functions), you would not necessarily need a branch for your B program.

Regardless, if you branched both projects, first go to your A library and merge your branch back into the trunk. Compile/link/fix errors. Then go to B and merge its respective branch onto the trunk of that project. Again, compile/link/fix errors.

I'm actually having to do something like this with one of the projects I'm currently developing; has a main application that makes use of various shared libraries. We use SVN, but the concepts are essentially the same.