CODEWITHSUNDEEP
gitgit-submodules
ruhrpottriot
ruhrpottriot

Reputation: 11

Git submodule remote server

The following 2 folders on my local computer contain shared libraries/helpers:

The libraries above should be submodules in my backend...

...and my frontend:

So far everything is configured and it works!

Furthermore I have remote servers for the frontend and the backend.

Now I want to get the following: If I commit a change in one of the shared libraries I want to push the changes into all 4 repos with one git push (backend, frontend on my local computer and backend, frontend on the server).

If this is not possible: If I commit a change in a library I want to push the changes at least into my 2 local directories with one push. If I push the changes of one of the local directories into the remote server, the changes of the submodule should be pushed automatically to the remote directoty as well.

Changes in the shared libraries should only be possible in the shared-folders and not in the backend or frontend!

Thanks for your help!

Upvotes: 1

Views: 205

Answers (1)

underrun
underrun

Reputation: 6841

Now I want to get the following: If I commit a change in one of the shared libraries I want to push the changes into all 4 repos with one git push (backend, frontend on my local computer and backend, frontend on the server).

This is not possible with a simple git push. You can't "push" changes to a repo with a working copy - you can only push to a bare repo. For repos with working copies, you can only pull from somewhere else.

Submodules are a bit tricky to work with, and I've tried doing something like what you are talking about before. I totally abandoned the idea in favor of making what was in my git submodules more generic and able to be installed on the system as a stand alone thing.

Look at it like this - if the code in your libraries is sufficiently separable from your main repo then it is logical to treat it like its own package and develop/deploy it separately. If the code in your libraries is strictly dependent on your main repo then it should all probably just be one repo anyway.

Not to say there isn't a case for submodules - I still use them. And if you want to use them you've got to follow their rules:

  1. commit and push submodule changes in the submodule as the changes are made
  2. after changes in the submodule are pushed
    • commit the submodule changes in the parent repo
    • push the parent repo
  3. if any repos need the changes from the submodule
    • pull the submodule in the other repo
    • resolve conflicts and push any changes
    • commit the submodule changes in the parent repo
  4. if pulling the submodule to other repos resulted in changes
    • go back to step 3 for the original repo

It seems cumbersome, but submodules aren't really any different than any other repos. They stand on their own and you need to treat them that way. Additionally, from the perspective of a parent, a submodule folder is just a file with an sha1 hash in it. the git submodule commands are just convenience scripts for operating on repositories referenced by the parent.

UPDATE

While you can't do this with pure git in a single command, you could write a bash script that did most of it for you and you could combine it with git hooks to automate it.

It wouldn't be able to automatically handle conflict resolution and you might be left trying to figure out the state of 4 separate repos if something goes wrong.

I wouldn't recommend a solution like this though. It is overly complex and potentially fragile and the number of possibilities you would have to cover to make it robust flexible and generic would be vast.

Upvotes: 2

Related Questions