I have an application with name app1 and I have a git repository with one branch(master).Now I want to create new application(app2) .Now I want use master branch as ancestor of these two application because of many shared code and libraries.So I created a new branch with name app1,and I want to delete all code and libraries that is belong to app1,and let remain all shared code in master branch,So I don't know how peaple are doning this after that? what is the soulition?

CodePudding user response：

Branches—or more precisely, branch names—in Git do not have ancestry relationships. No branch name is the parent or child of any other branch name. A branch name is simply a way that you have to tell Git: Please remember some particular commit hash ID for me, while giving me some extra features.

Tag names in Git work much the same: Please remember some particular commit hash ID for me, while giving me some extra features. The key differences between branch names and tag names are the extra features involved:

• A branch name moves easily. That is, the remembered hash ID today, and the remembered hash ID tomorrow, are likely to be different. The kinds of motions that are "encouraged" (as in, that Git will do on its own, without any extra effort on your part) are what Git calls fast-forwards, which are a little tricky to describe. But you're allowed to move the name around, from commit to commit, and people should expect motion.

  (Branch names also let you set an upstream and have some other features.)

• A tag name should, ideally, always describe one particular commit, forever. As such, Git won't let you "move" a tag name without using extra effort. A tag name can be used in conjunction with an annotated tag and this annotation allows you to store extra information, such as a PGP signature affirming—in a verifiable, digital-signature sort of way—that you personally endorse this commit. This digital signature is not transferable, so if someone should take this annotated tag and make it select some other commit, the digital-signature-verification process will show that this is now a faked endorsement, not the one you made.

  Git can't stop you from moving a tag (with git tag -f, or by deleting a tag and then creating a new different tag that uses the same name), but people can and should expect tags not to move. That is, once a tag like v1.2 exists, it should name the same commit in that repository forever.

So your desire (to make a branch name an "ancestor" of other branch names") is already in trouble. Things only get worse from here though:

Now I want use master branch as ancestor of these two application because of many shared code and libraries. So I created a new branch with name app1, and I want to delete all code and libraries that is belong to app1, and let remain all shared code from master branch ...

Git isn't actually about branch names in the first place. Git is about commits. Every commit is numbered, with a unique hash ID specific to that one particular commit. This number is unique across every repository everywhere so that given any two repositories, if they hold the same commit hash ID, they literally hold the same commit. These commits, with their unique numbers, are what Git is about.

Each commit contains a full snapshot of every file, like an archive (tar or WinRAR or zip archive), plus some metadata: some information about the commit itself, such as the name and email address of the person who made the commit. (This information is easily spoofed, hence the idea of PGP-signed tags above. You can PGP-sign individual commits as well, but there are tradeoffs that seem to make this a bad idea for most projects.) Everything inside the commit is read-only. No part of any commit can ever be changed.

What this means is that:

... I want to delete all code and libraries that is belong to app1, and let remain all shared code from master branch ...

You can make new commits in which the app1 code does not exist, and put those commits on some branch. But the existing commits, where the code does exist, continue to exist.

You can make a new and different repository (with new and different commits, which get new and different unique hash IDs) in which you never store the app1-specific code. This is probably the way to go.

Having made such a repository, you can then choose whether to add, to that repository, commits in which the app1-specific code is added. Git commits all de-duplicate any identical files, so adding code while re-using existing code takes the same amount of storage (except for some minor overhead) as storing just the new code. That is, your master branch can be the library, and your app1 branch can be library-plus-app. But this may be painful organizationally. (Or it might be the way to go.)

Another way to organize this is to have the library repository just be a library repository. A completely separate repository, that you git clone separately, contains just the app1 code. To build the app, you clone both repositories and build both. This may be less-painful organizationally (or, again, it might be the way to go).

Should you decide to use two separate repositories, you can then, if you like, link one repository to another as a "submodule". I personally dislike submodules (to put it mildly) and would try to avoid this, but they do work, provided you understand how they work. (The details are painful, such that many users call them sob-modules. They really do not work the way people expect them to work at first. But they do work!)

So I don't know how people are doing this after that? what is the solution?

There is no single solution. Git provides tools, not solutions. "How best to use these tools" is a matter of opinion.