Writing in the front

The company needs to develop an internal system that requires every department to access. The boss ordered, and the time limit was short, so haohaotang’s hundreds of people transferred over.

Simple things get complicated when there are too many people, and so does the world of development.

Pain points

When collaborating with Git on a large project with hundreds of people, think about our pain points:

  1. The project is too large and the clone waiting time for each person is too long
  2. After a while without pull code, you’ll find hundreds of updates waiting to be pulled
  3. One person submitting error, hundreds of people standby (author’s real experience)
  4. Code backtracking is difficult, and finding specific changes is like looking for a needle in a haystack

The solution

This is where Git submodules come in handy.

The first requirement is of course a reasonable architecture. Due to the confidentiality principle of the company, the project will not be posted here. This article mainly describes the use of the collaboration neutron module.

The project structure

The main structure of the project looks something like this:

└ ─ ─ the SRC ├ ─ ─ layout// Public layout directory├ ─ ─ the public// Public page directory├ ─ ─ the router// Route entry├ ─ ─ the components// Common components├ ─ ─ modules// Module project Development directory (sub-module)| ├ ─ ─ TMS// The submodule must| │ ├ ─ ─ the components// Module generic components| │ ├ ─ ─ pages// Module page| │ ├ ─ ─ the router// Module routing| │ └ ─ ─ store// Module vuEX data| └ ─ ─...// Submodules├ ─ ─ app. Vue/ / components└ ─ ─ the main js// Project entry
Copy the code

Each department has a submodule, and each submodule must contain the Master (production) and Dev (development) branches (gitFlow workflow is recommended).

The development process

Cloning project

As with all WebPack projects, SRC is just business code, and development configuration is placed outside SRC, so running the development environment first requires cloning the main project.

$ git clone https://github.com/test/main.git
Copy the code

Adding submodules

Of course, we usually do not use the master branch for development, and the correct position is to switch to the dev branch immediately after the Clone project (in principle, the business group does not need to pay attention to the development of the main project, the main project is taken care of by the architecture group, but in order to keep the code up to date and add submodules into the dev branch, So switch to main branch dev).

$ git checkout -b dev origin/dev
Copy the code

If you already have submodules in your project, you’ll notice that there are already submodules in the Modules folder, but obviously those modules are now empty (as expected, we don’t need to worry about other modules). At the same time, there is a.gitModules file in the root directory of the project, which is as follows:

[submodule "modules/suba"]
	path = modules/suba
	url = https://github.com/test/suba.git
Copy the code

Here is your submodule associated file. A new record is added for each submodule you add, which is automatically generated for the first time you add Git submodules.

Now that you have your development environment, you need to associate your submodules:

$ git submodule add https://github.com/test/subb.git modules/subb
Copy the code

When you add a submodule for the first time, you pull the entire item, open the muodules/subb folder, where the entire submodule item is listed intact, and add a new module to.gitModules to record modules/subb.

Edit submodule

Similarly, we should not make any edits on the master branch of the submodule, so we should switch the submodule to the dev-based development branch.

Go to the submodule directory:

$ cd modules/subb/
$ git checkout -b feature/some-change origin/dev
Copy the code

When you make some changes to a submodule, you want to push those changes to the remote.

$ git commit -am 'test commit submodule'
$ git checkout dev
$ git merge feature/some-change
$ git push origin dev
$ git branch -d feature/some-change
Copy the code

At this point your submodule changes have been committed to the remote, but if you look at the differences in the root directory of the main project, you’ll see that there are some more changes in the main project:

$ cd. /.. / $ git diff > diff --git a/subb b/subb index 433859c.. b78179a 160000 --- a/subb +++ b/subb @@ -1 +1 @@ -Subproject commit 433859c90e539d2a1b9fda27b32bef0d0acae9e6 +Subproject  commit b78179adab252a524ff2a41d6407a7daa6dad34fCopy the code

This is because you changed the submodule subb and committed it, but the pointer to the main project still points to the old COMMIT ID. If you don’t commit the change, someone else will pull the main project and update the submodule with Git subModule update and still pull the code you made before.

Submit the main project as well:

$ git commit -am "test commit submodule"
$ git push origin dev
Copy the code

That way, your changes have all been committed.

New member

When you add a new member to your submodule and need to pull code:

$ git clone https://github.com/test/main.git
$ git checkout -b dev origin/dev
$ git submodule init
$ git submodule update subb
Copy the code

Git subModule update [submodule name] specifies the name of the submodule to be pulled. If you need to update all submodules, just use Git subModule update.

Then the new members can also continue our development process above.

Deleting a Submodule

Git does not have a direct command to delete submodules, so you can only delete related files gradually:

  • Delete submodules in version control:
$ git rm -r modules/subb
Copy the code
  • Delete the following content in the editor, or run a commandvi .gitmodulesDelete from vim:
 [submodule "modules/subb"]
          path = modules/subb
          url = https://github.com/test/subb.git
          branch = dev
Copy the code
  • Delete the following content in the editor, or run a commandvi .git/configDelete from vim:
 [submodule "modules/subb"]
         url = https://github.com/test/subb.git
         active = true
Copy the code
  • Delete. Git cache module:
$ rm -rf .git/modules/subb
Copy the code

Next commit the changes:

$ git commit -am "delete subb"
$ git push origin dev
Copy the code

Publish the project

When the whole development process is over and it’s finally time to release, of course you need to update all your submodules in the main project:

$ git checkout master
$ git pull origin master
$ git submodule update
$ yarn build
Copy the code

Now you can publish your entire project at 😊, and write about using submodules in collaboration here. If you have any questions, please leave them in the comments.

— The End