I am working on a project with 2 repositories as Front-End Repository and Back-End Repository.

I also developed a Testing environment for my co-workers to test every feature / bug that i am publishing.

My current problem is that i need to build a different version from an older commits on both repositories. So what i thought of is to clone each project to a new folder, checkout to the specific commit, create a new branch from that commit, then build a new version from the new branch instead of 'master'.

Its important to say that i am just learning how to work well with git so i want to make sure i understand my different options for any issues.

Thanks in advance for your answers.

As @Casper Bang suggested, I am adding more info on my situation:

So as i mentioned, I am constantly developing a program which runs on a IIS server.

I am developing the software from my first day at work, without any supervisor that would argue the best practice for different cases. As things ran quickly and the Time To Market demand were high, i developed with one branch and built every product in my own computer. As the program went bigger, I created a Jenkins pipeline to make sure every version created was built through a certain flow. Then I managed to work with feature branches, to make it a bit more backwards compatible -> and each time i wanted to make a product I would merge every branch into master, for creating more organized versions.

So The current problem is actually that the features are not working perfectly as there are some rejects from my co-workers. However I do need to create a new version during the next few days, based on the latest PRODUCTION version, with a tiny fix which will be a 'temporary version'. This way i could release the version soon enough, and split the new versions away while working on them to make them better. because the fix is about 2 lines of code, I can make sure that I will add them both to the Quick PRODUCTION version AND to the future versions manually.

I think it is also important to say that there 5 Different branches merged to master since the last production versions, and its all merged to the current master branch, in each repository.

CodePudding user response：

I am working on a project with 2 repositories as Front-End Repository and Back-End Repository.
My current problem is that I need to build a different version from an older commits on both repositories.

I would recommend creating a third "parent" repository, in which you add the front and back repository projects as submodule.

A submodule is a reference to a fixed commit to another repository, which means you can modify the parent repo in order to checkout the exact commits you need from those two projects.

CodePudding user response：

There are a million different solutions. Stepping back a bit, one could also argue whether two strongly-related systems should be one or two git repositories.

Where is the testing environment hosted? how? If you did git-flow, you'd simply have a staging/dev branch, and the head of that should correlate and work together. And/or at least the production branch. You can also, depending on your infrastructure, simply release a specific commit version to whatever cluster/containerization environment you use, and release the two that work. I'd argue that if you are doing things "right", the question is less related to git, but more to the actual environment. Even more so, I'd say that you should never have code in your primary branch that isn't compatible with the primary branch of related projects. If something isn't backward capable, you should wait with merging it till everything else is up to speed too.

As you mention that you are new to git, I'm thinking if you are new to other aspects of development as well. So maybe share a few words (i.e add to your post) regarding everything else in your setup. I'm hoping you aren't simply SSHing into a server and changing branches and doing releases like that.