How to use Git Subtree to share code between Angular projects

Share on facebook
Share on google
Share on twitter
Share on linkedin

This video covers how to use Git subtree to share code between Angular projects.
Git subtree contains utilities to sync a part of a repository (subtree) ensuring that each client decides themselves when they want to sync changes with the upstream.

Thank you for watching.

I’m going to do another post soon on using Mono repos with Angular.

Subscribe so you don’t miss it:

[blog_subscription_form]

Transcript:

0:00:00.530,0:00:06.830
hello this is Christian Lüdemann and
today’s video is about how you can share

0:00:06.830,0:00:16.109
angular code easily using git subtree
the way I started looking into this was

0:00:16.109,0:00:24.570
I needed some way to share code easily
between some angular projects and the

0:00:24.570,0:00:32.160
problem is that conventionally you
either do npm packages or you do mono repo

0:00:32.160,0:00:39.480
or you just copy paste code or use git sub modules and all these

0:00:39.480,0:00:47.489
have some drawbacks if you take the npm packages the problem is

0:00:47.489,0:00:52.850
that it’s it’s a lot of overhead to
managing all the semantic versioning and

0:00:52.850,0:00:58.469
if you take the monorepo the problem is that you need

0:00:58.469,0:01:05.309
a lot of CI tooling to get that working
and do all the regression testing when

0:01:05.309,0:01:12.270
you share it change the shared parts so
what I found out was that if you use git

0:01:12.270,0:01:17.880
subtree you’re gonna have a very easy
set up that doesn’t require if you

0:01:17.880,0:01:25.470
change anything on your CI server and it
will just work like a normal git

0:01:25.470,0:01:32.970
repository herewe want to create some
shared folder here where we’re gonna put

0:01:32.970,0:01:37.650
some code for me wants to share between
all our angular projects and then we later

0:01:37.650,0:01:45.180
gonna use get subtree to synchronize
this shared code with the shared

0:01:45.180,0:01:54.890
repository so we’re gonna create this is
gonna be called

0:01:56.780,0:02:04.469
and what we want to do is we want to
look at this shared hope we already have

0:02:04.469,0:02:10.440
and we want to move that into the shared
lib here so all our projects can use it as

0:02:10.440,0:02:15.880
well and of course we’re gonna
only take the generic solution that our

0:02:15.880,0:02:22.590
parties can benefit from to the spinning
em would be a generic component that

0:02:22.590,0:02:40.450
could benefit from so let’s move that
over just move it to shared and it’s

0:02:40.450,0:02:44.430
probably on I need to fix some

0:02:51.740,0:02:53.800
you

0:03:15.730,0:03:35.709
this is as you know and lets us ensure
that it’s working here we had spinach

0:03:39.970,0:03:43.300
it’s pretty good

0:03:46.510,0:03:53.840
what we see here is the different gets
up free commands you can use we have the

0:03:53.840,0:04:04.310
pull then is for updating the get shared
library inside here and had the push

0:04:04.310,0:04:13.250
that is gonna update the upstream and
what the push is doing it is gonna do a

0:04:13.250,0:04:18.440
split first that is it’s gonna take all
these changes here by going through the

0:04:18.440,0:04:26.750
get history and it’s gonna move all
those changes it detects to a separate

0:04:26.750,0:04:32.240
branch which prevents name here which is
gonna called split and we’re gonna

0:04:32.240,0:04:41.360
rejoin this massive ends here with this
command so ensure that next time we do

0:04:41.360,0:04:45.710
this it doesn’t need to iterate through
the whole get history again so it’s

0:04:45.710,0:04:51.680
gonna make it faster for future runs and
then we gonna squash because the only we

0:04:51.680,0:04:57.440
don’t want to kata are versioning with
too many comets and after that we kind

0:04:57.440,0:05:03.280
of push it to the master so let’s see

0:05:08.139,0:05:17.949
husband in 4:35 commits and it’s gonna
move all the changes of this folder to a

0:05:17.949,0:05:25.280
branch called split now we have a brain
SIA called split let’s check that one

0:05:25.280,0:05:27.310
out

0:05:27.759,0:05:35.930
see we have it’s been added here and we
want to push this one over so this one

0:05:35.930,0:05:47.470
here so we can just go back to master
and we just to this command here

0:06:02.559,0:06:12.459
and I look here we see that they haven’t
spin in here and so how easy it is to

0:06:12.459,0:06:18.309
just do the people pool of the push
command and that’s all you need to do so

0:06:18.309,0:06:24.099
with kids up free you don’t need to do
some faint stuff on your CI you don’t

0:06:24.099,0:06:30.219
need to worry about semantic versioning
and all the trouble with updating a new

0:06:30.219,0:06:35.769
version determiners can be mine are made
and then consumed how it’s gonna work

0:06:35.769,0:06:41.829
with with the clients but this method
you you can decide when you want to pool

0:06:41.829,0:06:46.869
you’re gonna have your own copy and even
if it doesn’t work with your client you

0:06:46.869,0:06:51.069
can just modify make it work and just
push it back up again

0:06:51.069,0:07:00.899
you have your own copy and what you can
do to take this further in the future is

0:07:00.899,0:07:06.519
when you start using this I would I was
like using is this if I had two projects

0:07:06.519,0:07:12.039
that was kind of related and they
started to have lot of shared code

0:07:12.039,0:07:17.319
that’s that’s gonna be an easy way to to
share it and maybe these two projects

0:07:17.319,0:07:22.899
was located in the same department of
the business you were working with then

0:07:22.899,0:07:30.789
later as these she had the shared
library should be shared with all the

0:07:30.789,0:07:36.279
people in the organization you want to
set something up on the CI that might

0:07:36.279,0:07:43.209
also publish this one and support
semantic versioning or you can just keep

0:07:43.209,0:07:50.189
using this one if if not having semantic
versioning is okay for your needs

0:07:50.189,0:07:55.289
thank you for watching and remember to
subscribe

Do you want to become an Angular architect? Check out Angular Architect Accelerator.

Related Posts and Comments

How to Set up a CI pipeline with Azure Pipelines and Nx

It goes without saying that having a CI pipeline for your Angular apps is a must. Setting one up for regular Angular apps is fairly straightforward but when you have an Nx monorepo there are certain other challenges that you have to overcome to successfully orchestrate a “build once, deploy many” pipeline. This post will

Read More »

How to Set Up Git Hooks in an Nx Repo

Git hooks can be used to automate tasks in your development workflow. The earlier a bug is discovered, the cheaper it is to fix (and the less impact it has). Therefore it can be helpful to run tasks such as linting, formatting, and tests when you are e.g. committing and pushing your code, so any

Read More »