How to Keep Two Git Projects in Sync

gitworkflows

I'm developing a Python library, and I'm also developing some code that uses it. Currently they are in the same git repository, but I want to separate out the library part into a separate repo, in preparation for eventually* releasing it.

However, I'm unsure of the right way to work with two repositories. The library has a complex API that's likely to change a lot as I develop it, and at this stage of the project I'm usually developing new features simultaneously with code that uses them. If I need to restore things to a previous working state, I will need to roll both projects back to previous commits – not just the last working state for each project individually, but the last pair of states that worked together.

I am not a very advanced git user. Up to now I have used it only as an undo history, meaning that I don't use branches and merges, I just do some work, commit it, do some more work, commit that, and so on. I am wondering what's the minimal change to this workflow that will allow me to keep both projects in sync without worrying.

I'd like to keep things simple as simple as possible given that I'm a single developer, while bearing in mind that this project is likely to become quite complex over time. The idea is to make small changes in order to minimise disruption at each step.

*A note on what I meant here: the project is in nowhere near a releasable state, and I'm not planning to release it in anywhere near its current state. ("Repository" in this context means "folder on my hard drive with a .git in it", not a public repository on github.) I asked this question because I thought that putting it in a separate repository would be something I needed to do early on for the sake of my own management of my code, but the answer from Bernhard convinces me this is not the case.

Best Answer

but I want to separate out the library part into a separate repo, in preparation for eventually releasing it.

Separating the library has a few implications. One of them is that others will use your library as well. At that point, you cannot just roll back changes in your library, as it may have unexpected effects on other projects that use this library. In the project using it, you can still roll back whatever you want. You can rely on different released versions of the library in the worst case. If you are rolling them back both at the same time, do you really have separate repositories, or are you just making life more complicated?

The library has a complex API that's likely to change a lot as I develop it

Changing the API continuously is going to be a huge pain in the neck in the long term. Interfaces are rigid. Changing an interface should not be taken lightly, because of the downstream impact on other projects. When releasing a new version of the library, you have to think about backwards compatibility too.

Considering that you are the sole developer at the moment, I recommend to do either one of these:

  • Keep the library and the project in a single repository, until you find that the interface is rigid enough. Then separate it when you can make a first released version
  • Don't develop the library and the code using them at the same time. Write unit tests that tests for each method that your interface offers in isolation. When everything works as desired, start working on the project using them.
Related Topic