如何在Web应用程序的不同开发阶段使用git分支？

Question

I'm mostly new on Git, and I just recently learned the basics of git branching. One of my troubles now is how to set up git branching for use on my web project.

I use the main branch for production, and another one called beta for live changes and feature testing. This branch lives on a subfolder of the webserver, accesible via the beta. subdomain.

The main problem I have is that, as a web project, some URLs, API Keys, etc are defined on the code as constants. In order to the project to work properly, I have to change the API keys and URLs on code, and that changes will be obviously pushed to the main project when I merge the branches.

I have no idea how to issue this, without having to edit those files manually on master each time I merge it with beta , and dealing with conflicts on the next merge.

Do you have any hints about how to face this? Any response will be appreciated ^^

Answer 1

Check those 2 links:

• GitHub Flow
• A successful Git branching model

For different configurations. You can create such folder structure:

-configs
  -dev
    conf.ini
  -beta
    conf.ini
  -live
    conf.ini
-src
    conf.ini

Put all your config files into this folders according to env and commit them. After it remove all your files( src/conf.ini ) from index and put them under gitignore and after it you can make changes at config folders and copy those files to original. They will not be modified, because they are under gitignore .

Answer 2

The core idea for something like this is to make sure you use separate commits for the changes you want to propagate from BETA to PRODUCTION vs the changes you don't want to propagate. You should merge normally any commits you want to propagate, but you "fake merge" the commit(s) you don't.

You should be comfortable with merging before you use a merge workflow like this. You need to realize that each time you merge BETA into PRODUCTION, you will be incorporate ANY and ALL commits made in BETA (that haven't already been merged) into PRODUCTION. Once a commit has been merged (or more technically speaking, once the commit is reachable from PRODUCTION), it won't be merged again in the future. There's a way to "fake merge" a commit so it will appear to have been merged in without really applying changes and so it will be ignored in future changes.

For a workflow like yours, you would do something like this:

$ # Create BETA branch
$ git checkout -b BETA PRODUCTION

$ <make BETA-only changes>
$ git commit -m "BETA-only changes"                       # => commit #3612072

$ # "Fake merge" all changes from BETA that have not already been merged into PRODUCTION,
$ # i.e. "mark" those changes as having been merged without really merging them
$ git checkout PRODUCTION
$ git merge -strategy=ours -m "Fake merge BETA => PRODUCTION" BETA
$                                                         # => commit #8eae339
$ # Okay - now future merges will ignore that commit

$ # Make changes in BETA branch
$ git checkout BETA
$ <make changes>
$ git commit -m "Real change in BETA"                     # => commit #3cd69ad

$ # Real merge all changes from BETA that have not already been merged (or fake merged) into PRODUCTION
$ # i.e. this should ignore the changes you "fake-merged" before
$ git checkout PRODUCTION
$ git merge -m "Real merge BETA => PRODUCTION" BETA       # => commit #bc26f91
$ # Okay - PRODUCTION should have just the most recent changes and not the BETA-only changes

Rinse and repeat. Ideally, you won't make any more BETA-only changes and it will "just work". If you do need to make future BETA-only changes, make sure those changes are committed in their own commit and then "fake merge" those changes

Your repository should end up looking like:

*   bc26f91 Oct 31 Real merge of changes from BETA into PRODUCTION
|\
| * 3cd69ad Oct 31 Real change in BETA
* |   8eae339 Oct 31 Fake merge BETA => PRODUCTION
|\ \
| |/
| * 3612072 Oct 31 BETA-only changes
| |

===

Edit: A similar issue crops up when changing version numbers in branches, eg advancing the version # for a release in your maintenance branch and then pulling that bugfix into your mainline development branch:

Git merge strategy for integrating 'patch' branch into 'minor', 'minor' branch into 'major'