2

We have two versions of an admin site, a "simple" version and "full" version, which exist on branches of the same names. The simple version has a single report, and the full version offers tabs with additional reports. The two versions are separate apps hosted at different urls.

Generally new development and bug fixes occur on the "full" branch, even though the work is often relevent to both branches.

My current (hacky) process is:

  1. Make changes on "full".
  2. Merge the changes into "simple"
  3. Manually remove the extra tabs showing the additional reports. This just involves deleteing a couple lines in a single view file.

My question is: How can I accomplish this same "syncing with exceptions" in git without resorting to manual file changes?

Jonah
  • 15,806
  • 22
  • 87
  • 161

2 Answers2

2

This doesn't seem like a problem that should be solved with source control. You could do it by having a single file that controls the set of available tabs, and have two versions of that one file (one for the "full" site and one for the "simple" site), and then never change that file. But generally the approach here is to have that logic reside in the program itself, and have a configuration, license file, or some other type of control mechanism define whether the "simple" or "full" set of tabs is shown.

Chris Shain
  • 50,833
  • 6
  • 93
  • 125
  • I agree with you, but it's also a problem that I'm sure git *can* solve (I think), and I'd like to know how to solve it with git, to improve my git skills. – Jonah Dec 19 '15 at 01:25
  • 1
    In that case maybe this article will help: https://medium.com/@porteneuve/how-to-make-git-preserve-specific-files-while-merging-18c92343826b#.6t9lj2716 – Chris Shain Dec 19 '15 at 01:27
1

If you are the only one using the simple branch and don't mind changing it's history

Assume we start from a state where you only have the full branch:

git checkout full
git checkout -b simple # create simple branch
# remove extra tabs
git commit # can make as many commits as you like

Now say you need to update the full version:

git checkout full
# make changes to full version
git commit

Now the important bit:

git checkout simple
git rebase full # now the simple branch is the same as the full branch but with the extra commit on top

The rebase command may lead to a merge conflict if you change something in the full version which conflicts the change in the simple version, which you resolve in the standard way.

texasflood
  • 1,571
  • 1
  • 13
  • 22
  • Ah, interesting! So instead of merging I just keep moving simple forward, on top of full, with rebases... – Jonah Dec 19 '15 at 01:40
  • Yes, though the only drawback with this method is that you are modifying the history of the simple branch. So if multiple people use the branch, it may be better to do a merge and then cherry-pick the commit that removes the tabs – texasflood Dec 19 '15 at 01:44