Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Let me start by saying that my GIT knowledge is fairly shallow, so I'm guessing that there might be something I'm missing.

THE SETUP:
As an example, we have a project which is being developed as a collection of plug-ins/modules. Some modules, such as contact management, depend on others, such as validation. Each module has it's own branch.

CURRENT WORK FLOW:
Our validation module is being concurrently developed with our other modules, just in a separate stream. In doing so, I am finding that I am having to do a lot of checking out back and forth (as well as a lot of stashing (and merging, but that I'm fine with)).

For example, say I'm developing module_x which needs a new validation rule (which will have uses in other modules as well) ... I then:

  1. stash my work
  2. checkout the validation branch
  3. write the rule
  4. commit
  5. checkout the module_x branch
  6. pop the stash
  7. merge the validation branch into module_x.

Now, if I come up with an improvement for something in the validation branch (or just need to fix a bug), I have to go through all that all over again.

Between new development, refactoring/improvements, and bug fixing, I feel like I'm spending entirely too much time just switching back and forth between developments streams, and can't help but think that there's a better way.

DO's and DONT's:
Is this really how it's done, or am I completely missing the bigger picture? :)
What works for you?

share|improve this question

closed as primarily opinion-based by gnat, Glenn Nelson, Dynamic, Martijn Pieters, ChrisF Dec 21 '13 at 14:04

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

    
Generally I would not see git as the best tool for this. I would create a separate repository for each part of you project. Then one for you full project and load the dependencies with a tool like Composer. –  Luc Franken Nov 22 '13 at 9:57
    
Hmm, that's a cool idea. Thanks Luc. –  mOrloff Nov 22 '13 at 14:49
    
Also see Composer versioning, that will get your project stable until you actually want to use a more recent version of the module. –  Luc Franken Nov 22 '13 at 16:05

1 Answer 1

up vote 2 down vote accepted

You may be confusing "module" with "branch." Just because two classes are in two entirely distinct source code files and wind up in two entirely different distibution files does not mean you need to revise them on different branches.

Ideally, you would have a single personal branch for your entire project, so than when you share your revisions to the various modules they belong to they are done atomically. (And you share to a development branch with your team once your personal development is in a shareable state, and the development branch is what eventually points to the formal build.)

If the modules are intended to be separate for architectural reasons, you probably don't want to be working on both implementation and validation. Someone else should be the one to write the validation of what you did, so that you get an automatic check against unspoken assumptions. And while that "should" is of the "everyone should pay their taxes on time and in full" kind, you can get a smiliar effect by simply working in sequence.

A branch in git is meant to represent a period of change to the whole project, not just to part of it.

share|improve this answer
    
Ahhh ... makes sense. Thanks-a-bunch. –  mOrloff Nov 22 '13 at 14:49

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