CODEWITHSUNDEEP
gitdeployment
christopher_b
christopher_b

Reputation: 958

Git workflow for local commits, upstream commits and deployment

I know there are a lot of posts about git workflows, but I couldn't find exactly what I'm looking for: recommendations about best practices for the following workflow:

I have a web application that deployed via git. The application developers release updates via a public git repo. I also have my own changes that need to be applied. What would be the best way to handle this?

What I've been doing: I created a local deployment repo, cloned from upstream. This is served via gitolite, so it's a bare repo. I have a clone of this repo, on which I apply changes, and push them back to the deployment repo. When changes are published to the upstream repo, I've been incorporating them into this clone, using the recommended command: 

git fetch && git pull --rebase

I then push to the deployment repo. The problem is that I start getting a ton of merge conflicts on any files that I've changed. The same file will give me many conflicts during the rebase. I'm looking for an approach that can be more or less automated, but I don't quite get git enough to understand what the problem is.

Can any git gurus offer some advice? Let me know if anything needs clarification. Thanks.

Upvotes: 2

Views: 274

Answers (2)

Esme Povirk
Esme Povirk

Reputation: 3174

Your current workflow would be fine if you dropped the --rebase from git pull. Then pull will do a merge (the default) instead of a rebase, and you will have fewer conflicts. Of course, there will always be situations where git cannot resolve conflicts on its own, so the process cannot be fully automated.

The problem is that rebase takes many steps, going back through your entire history and resolving each change that you've made on top of upstream. This is unnecessary for your scenario, and even counter-productive because it makes it impossible to tell when your changes were made relative to upstream's changes. Merges will work better because they take only one step and do not have to go back very far in the history (only to the previous merge).

If you're still getting more conflicts than you would like when you're doing merges, you will have to find ways to reduce the diff between your revision and upstream (which you can easily check with git diff after doing a merge), or move your changes to places that upstream does not modify very often (or that do not exist in upstream).

Upvotes: 1

Lazy Badger
Lazy Badger

Reputation: 97285

I don't want to know and remember crappy, ugly, stupid, "original" Git-jargoon, so I'll write recipe in the form of "needed actions", task of translating it to command I leave for you

Preparation

Send your current workflow to dustbin

Actions

  • You have to have one repo with two branches (vendor and own). Vendor branch linked to remote repo of upstream, your branch is single place, where you store own changes. Branch Own must be created from Vendor, in order to get common parent for all files in both branches, files in Own have to be patched with your changes
  • Sync with upstream performing by updating Vendor branch from remote and merging with Own branch after it (changes from Vendor merged to Own)

You'll have conflicts only for changed by both sides (you and upstream) files on merge stage

Upvotes: 2

Related Questions