3

This question already has an answer here:

My background:

I was programming for many years, but have never used a version control system. I felt, that such a system would save me a lot of time and allow me to be more productive, but I never got around to learning one, because of a lack of time that I would need to spend for learning such system.

I've finally got myself together and did a research on what VCSes exist and what are their differences. Then, I've had to work on some project, so, I've let that gathered CVS information to sink in for a few more months in my head.

While the information was sinking, I've made my choice with Git and started learning it. I've finished the book, called 'Git Magic', read many online howtos and tutorials and played with several interactive Git learning tools online. Now, I am almost finished with 'Git user manual'.

Question section:

Since I don't have a real experience, except for educational in it, please advice about the better way to use git in my situations:

  1. Let's say, I have a project (a program), that I am developing.
    Over the years, it grew with its library of functions/modules.
    I've started one more project (a different program), where I use the same library with those functions.

    Do I make those 2 programs and the library as one git repo, since they share the same libraries?
    Or split them to 3 different git repos: one for each program and one for the libraries, but then how do I test the program in the working directory or release the complete working project with all of the libraries?
    Do some kind of branching that will share the same library folder, but different programs each in its own branch?

    What's the best way to make those programs as individual programs, but so that they could use those libraries in each program?

  2. Another situation is:

    I have one completed project, that I vary for different purposes. I mean I have different modifications of it for a different task. So, for example, each task has the same core files, but different design. Should I use a different branch for each design, while keeping the core at its own branch, but, then how do I release or test the program in the way, so that the core joins with one of the needed designs. By design, I mean - each interface for it's core will have a different database structure, different forms, different event handlers, etc., but the same core routines.

marked as duplicate by user22815, gnat, Community Mar 15 '16 at 8:44

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 2
    I don't have time to write a full fledged answer, but for your point 1 you might want to have a look at submodules and subtrees – Iker Mar 14 '16 at 7:47
3

I would always use three repositories in the first situation you describe, because otherwise when you fix bugs in the shared code, you'll have to remember to do it in both places.

There are several ways of organising things so that you can get the library working with your programs.

  1. You can use git submodules

  2. If you are using an IDE that has a way of managing dependencies between projects in a workspace (e.g. Eclipse / Visual.Studio) then you can use that

  3. If you are working in a language that has a build tool that can manage dependencies (e.g. Maven for Java, NuGet for C#, Cabal for Haskell, etc) you can use that also.

As for your second scenario, I would refactor the project so that as much as possible becomes a library/framework, then use the same approach for that.

Not the answer you're looking for? Browse other questions tagged or ask your own question.