CODEWITHSUNDEEP
gitbranching-and-mergingcherry-pickgit-cherry-pick
Stan
Stan

Reputation: 7

How to recover from this Git setup

My small team of database developers and I started using Git for version control 6 months ago. We have 1 development instance and 1 production instance right now.

When I set up Git for the team, I created the "MASTER" branch, then put everything that was installed on the production instance into the folders. Then I created a "DEV" branch and put the things that were installed on the development instance into the folders (overwriting the old file if there were duplicates).

Then we continued doing all of our development on the "DEV" branch, then when want to install things on production from the development instance, I cherrypick a "DEV" commit from the "MASTER" branch. Then it asks me to manually merge because there are merge conflicts...

What do I need to do so that we can install from development to production easier without having to do cherry picking each time? Or do we need to start another repository going forward?

Here is an example of what I'm looking for.

I have made changes to these files in the DEV branch:

file1
file2
file3
file4
file5
...

Added these files in the DEV branch:

file 80
file 81

But I would like to only merge into the MASTER branch these files:

file2
file4
file80

Each file is a PL/SQL trigger or function or procedure.

Upvotes: 0

Views: 53

Answers (2)

user229044
user229044

Reputation: 239270

You're badly misusing Git's branching model.

Using branches to maintain separate divergent copies of files, such as putting environment-specific files on environment-specific branches, means you're giving up the ability to merge those branches back together, which means you're giving up on what makes Git most useful.

You should stop maintaining branch-specific files, and instead either:

  1. Move all environment-specific configuration out of the repository

    Put empty configuration files without real data in them into your repository. Populate these empty files with real configuration data in each environment where you deploy your app. In this scenario, your configuration data is not version-controlled; this is the correct approach for sensitive data such as API keys.

  2. Maintain all environment-specific configuration files on the same branch

    If you want to version control your configuration files, you should use unique names for each config file, specific to the environment to which they apply. For example, config.ini.production and config.ini.development. Then, in each deployed environment, symlink config.ini to the correct environment-specific file.

Once you've done this, you can simply merge your dev branch into your master branch, as Git is intended to work.

Upvotes: 2

Makoto
Makoto

Reputation: 106400

I've never used a cherry-pick to bring over work from one branch to another unless the intention was to completely abandon the branch the work originally lived on.

It seems like you simply want to merge your changes over, so you should just...do that - git checkout master && git merge development. You'll likely run into merge conflicts since the cherry-picked commits off of that branch will conflict with their counterparts.

To clarify that last point, if you have a commit A on your dev branch, and A' on your master branch, with A' = A due to a cherry-pick, then there will be a conflict there since A' was introduced without history.

Upvotes: 0

Related Questions