0

First of all, there is a good chance my brain is just fried and am not thinking clearly... I am not even sure how to explain this properly :(

My Repo Setup

I have two repositories, Framework, and Client1.

The first one has all the files, including some that will be modified in the Client repo. These are just considered placeholders, or example files.

The second repository, Client1, contains added files that don't belong to Framework, as well as modifying some of the files from the Framework repo.

The Client1 repo starts off by pulling the Framework repo in, then I add/edit files to fit the clients website. When the Framework repo files are changed, I merge them into the Client1 repo.

This will end up causing conflicts. There is a chance there could be many conflicts.

Can I git pull and accept only my files for the conflicts, in one command? Just to make things faster.

Or is there anyway to do this better?

EDIT: We have changed our framework so core files are not touched by the client. They instead put files in another folder if they need to override the framework file.

For example: The client needs to modify the Contact page controller which is located in /framework/application/controller/contact/index.php. The client creates a file in /application/controller/contact/index.php to override the one in framework.

We have also start to use Git-Flow.

Community
  • 1
  • 1
Draven
  • 1,467
  • 2
  • 19
  • 47
  • 2
    This doesn't sound like a job for Git; it sounds like you have chosen a poor architecture for your framework. Your client, which consumes your framework, shouldn't modify the framework's files in any way. Those files should be identical across all programs built on your framework. It's impossible to comment without knowing the language you're using, but generally your framework should be bundled up in some kind of library which gets included in your client application, and *never* modified by the client. – user229044 Aug 19 '14 at 00:54
  • You want to pull and merge from the `Framework` repository and do what exactly? Which set of files do you want to unconditionally merge on top of the other ones? The whole point of merge conflicts is that there are changes on both sides that git cannot merge without intervention. If you drop the changes on either side you lose one line of work entirely – Etan Reisner Aug 19 '14 at 01:41
  • @meager The language I am using is PHP. I understand that the Framework files should not be touched by Client but because of circumstances I have not described this is what we would "like". Perhaps you are right though, I shouldn't be using Git. I'll do research on an alternative. – Draven Aug 19 '14 at 01:45
  • @EtanReisner A `config.php` file for example. It contains PHP constants, paths to certain directories, database authentication, and so on. – Draven Aug 19 '14 at 01:47
  • 1
    The alternative would be an architecture in which you use and extend the core classes provided by the framework without modifying its source. It's not an issue of version control. RE your example of config.php: Typically the framework would provide something like a `config.php.example` that would provide configuration keys, but not values. You'd copy this to `config.php` in each client, and version-control *that* file. – user229044 Aug 19 '14 at 01:47
  • @Draven That doesn't answer the question. You can absolutely tell git to use the files (unmerged) from either side of the merge if you want to drop the entirety of changes from the other side (see the `ours` and `theirs` merge strategies). But I don't see how (in cases other than perhaps `config.php` that would generally ever be what you want, and even with `config.php` I'm not sure I see it). I also don't know that git can do that on a per-file basis automatically. – Etan Reisner Aug 19 '14 at 02:04

1 Answers1

1

From what I can understand based on what you have said, your framework repo is essentially a template you pull into your dev repo which you actively use for development. The issue you have is when you make changes to your framework, and you want to apply those changes to your active dev environment(Client1) that you have already built on and maybe even modified the framework you pulled in before.

I could not tell you of a specific command to ensure no conflicts, but I would like to pass on a bit of knowledge on ways this may be made better.

Firstly, I think that this framework should be something that more or less stays the same, you shouldn't technically be modifying it in your client very often, that being said, I think you may be re-inventing the wheel in some areas. In truth, frameworks already exist to do just what you want, and that appears to be generating a ready to go dev environment that you can modify and redeploy without worrying about conflicts and disasters.

There is a tool I have only recently started to study, but I know enough to say I think it will answer your needs very well. That tool is Vagrant, Vagrant is a tool centered around easily configuring and setting up a dev environment with all the plugins and structure you want, and most importantly, one of its merits is the ease in changing that structure (or "Framework") and simply running a command that will destroy and redeploy your environment. The best part, the dev environment is all set up in a config file, that can be reused anywhere. Pretty nice!

Additionally, take a look at Grunt, Grunt is a tool that allows you to setup tasks and handle manual processes in your dev environment. (It does lots of stuff including js minification and linting, less compilation, running console commands), you can configure tasks and chain them together however you like to create a nice efficient workflow, definitely worth checking out.

Finally, take a look at a git principle known as git flow, it is essentially a sort of paradigm that is meant to give you a solid, professional repository structure and deployment process. It may be overkill for your needs, but one of the biggest things it promotes is the use of a dev, test and production environment. Here is a great link that outlines it well, I could go into depth on these subjects, but the tools I have mentioned have great docs and explain things far better than I can.

It is worth it to spend a lot of time setting up a good environment to tailor to your needs, it may seem like a waste, I know for me I like to jump in and start getting my hands dirty, but a well built and managed environment will save you LOTS of time in the long run.

Anyway, good luck!

Jordan James Holt
  • 91
  • 4