How to realise a deployment branch in Git

This works for me, and I make only minor configuration changes to deploy (3 lines in config files).

1. Clone your repository from GitHub or wherever you keep it. To where you wish to deploy.

2. Run git checkout -b deployment origin/master.

3. Make your changes (push them if you like).

4. Whenever your master (or whatever branch you made the deployment from) has changes you want to deploy, simply git pull --rebase.

It's a simple solution and it certainly works for me, I can't speak to wether or not it this makes it "shi*t" as others suggest, but it is certainly very useful for our purposes.

I do some silly tricks like:

• Have the app read file config
• Add config.development and config.production but not config to the repository
• Have your deploy script not only clone the repository, but also then cp config.production config

Does that make any sense?

It works okay for me.

Quick answer is, don't ever merge the branches. In fact you don't need to merge them at all, just merge from development (aka "master") to deployment to merge fixes and generic changes.

Update Feb. 2021: Git itself is still not a good fit, but GitHub Action environment could help.

2009: I am not sure Git is meant to be used this way.

First a quick Linus advice, always "colorful" and informative ;)

Git very fundamentally tracks project state, not file state. Which means that you very much can NOT try to "merge a file". It is a senseless operation in git, and in fact, any SCM that allows it pretty much is doomed to be a total piece of sh*t (*).

(*) And I'm not saying that just because git doesn't do it. It's much more fundamental than that. Once you start doing per-file branching and merging, you've basically screwed yourself, and you'll never be able to work on the project as a "whole project" any more - you no longer have a well-defined history that actually is the history of the whole project.

---

There.

That said, you could:

• manage those config/doc files a separate git sub-projects (note: the use of submodules has been discussed here)
• or record partial merge (using "ours" strategy for files we don't want to merge), then --amend it.

---

Other solutions in this thread involve working on a "server-specific" branch on your deployment server

Development        Deployment

#origin/master:
x--x               $ git clone

                   # master
                   x--x

                   $ git checkout -b deployment origin/master

                   x--x
                       \ 
                        -- #deployment

                   $ .... #makes changes for config files
                          #or other specific deployment files

                   x--x
                       \
                        --d1--d2 # no need to push that branch ever.

#new developments
x--x--x--x

                   $ git pull --rebase #pull origin/master and 
                                       #replay current branch on top of it
                   x--x--x--x
                             \
                              --d1'--d2' #SHA1 rewritten in deployment branch
                                         #not important since this branch 
                                         #is not pushed (published)