Git SubModule: Git Submodule: Git Submodule: Git SubModule

In my opinion, the process of using submodules is the most noteworthy place, so I did not follow the above content as a “add, delete, change and check” series. “Reform”, I think, is the most important part. Which can be divided into:

  1. Modify the local submodule
  2. Update submodule content modified by others

Modify the local submodule

The operation to update the submodule is mentioned above

git submodule update --remote
Copy the code

However, the submodule is in a special state. Although the upstream changes are updated locally, the local submodule is in a floating HEAD state.

In the HEAD state, local changes are not “attached” to any branch if they are committed. Drifting content disappears after switching branches.

So what’s the right thing to do?

  1. Enter the submodule first, and then check out a branch.
  2. Then perform local operations such as commit
  3. performGit submodule update -- remote -- MergeMerges upstream changes into the local branch. If you forget -rebase or -merge, Git updates the submodules to the state on the server. And resets the item to a wandering HEAD state. To fix this error, re-execute 1 and 3.
  4. If there is a conflict between the local file and the upstream file, the normal solution is to resolve it before submitting it.
  5. Publish changes (push) : Perform them in the parent repositorygit pushadd--recure-submoduleParameter, which indicates the recursive submodule and can be set to two values: Check and on-demand. Check causes the parent repository itself to fail to push the child module. On-demand will try to automatically push the child module and then push the parent warehouse. If the child module fails due to other reasons, the parent warehouse will also push failure.

Merges changes to submodules

According to Gitbook, this is when the same branch forks locally and upstream and needs to merge, and the two are not ancestors and descendants (or a molecular commit).

The operation method is as follows:

  1. For upstream commits, check out branches
  2. Merge the branches checked out by 1 locally
  3. Resolve the conflict
  4. Back to the main project
  5. Check the records of submodules
  6. Resolve submodule conflicts
  7. Submit the master warehouse merge

Something I personally understand

The use of sub-modules mentioned above may be a bit convoluted, I personally think it is appropriate that our team’s sub-module workflow should be relatively simple.

  1. When the main project needs to develop new functionality on a sub-module, it needs to branch out into a sub-module within the main project and then develop it
  2. The submodule code needs to be committed independently, resulting in a COMMIT message recorded in the main repository
  3. Since the main project ultimately needs to be packaged, the version of the submodule is considered trusted as long as it is based on the Master
  4. Finally, after the whole version of the main project is verified and needs to go live, the branch of the submodule is merged into the master branch of the submodule, so that the next person to develop the submodule will include the latest code