We have branches prod for production releases and dev for ongoing development.
Our current flow:
We work mainly in dev branch and from time to time, customer decides which features/bugfixes he wants to come to prod and we cherry-pick them.
From my understanding, cherry-picks contradict to git flow model.
And so far I don't see how to adapt our flow to avoid it.
git flow assumes that you know beforehand should the change go to prod or not
Does community see any way around it?
UPDATE: I found that my question requires a better clarification of terms
What we use now
To implement a issue #12345
git fetch
git checkout origin/dev -B issue-12345 # new branch for issue #12345 from bug tracking system
# ... do many atomic commits
git fetch
git checkout origin/dev -B dev
git merge issue-12345 --no-ff -m "Bug #12345 - Bug title from bug tracking system"
# ... fix merge conflicts if any and commit
git branch -D issue-12345
git push
- We use atomic commits for each commit to have a clear intent. This simplifies review/blame/bisect processes
- We use custom message for merge as it is way more descriptive than default
Merge 'issue-12345' into 'dev' - We force non-fast-forward merges via
--no-ffbecause we want all issue to be represented as a merge. Sogit log dev --first-parentreturns high-level view of the tasks completed - We don't use
git merge --squashand its rebase analogues. We want whole task history to be preserved
When client decides that he wants to get issue #12345 into production
git fetch
git checkout origin/prod -B issue-12345
git log origin/dev --grep "#12345" --oneline --reverse # get all commits that have to be cherry-picked, usually that's only one merge commit (abcd1234)
git cherry-pick abcd1234 -x -m 1 # '-m 1' required for cherry-picking merge commit
# ... fix merge conflicts if any and commit
# ... repeat for other commit if any
git checkout origin/prod -B prod
git merge issue-12345-prod --no-ff -m "Bug #12345 - Bug title from bug tracking system"
# ... fix merge conflicts if any and commit (although that's unlikely for them to occur)
git branch -D issue-12345
git push
What git flow told us to do
See http://nvie.com/posts/a-successful-git-branching-model/ for more details
In terms of that article our dev branch corresponds to develop, prod corresponds to master, release branches are not used
According to git flow, only feature branches should be based on dev branch, and they are never merged to prod.
However hotfix branches should be based on prod and then merged to both prod and dev.
Why git flow is not applicable for us
- We don't know beforehand if the task will need to go to
prodbranch or not. - If we base feature branch from
dev, we won't be able to merge it toprodlater on if that will be requested (possibly much-much later) - If we base feature branch from
prod, we won't be able to benefit from other tasks completed before.
Example 1
Let's say we have a task #12345 to implement a new Contact Us page. And then we have a task #23456 to change the page's background color from white to yellow.
We based our issue-12345 branch from prod and then merged it into dev and waiting for approval to merge it into prod.
Then we start working on issue-23456 and based on prod again. But prod code doesn't even have any mentions of Contact Us page yet. So we'll have to do some quirks such as merging issue-12345 branch into issue-23456 first.
That's complicated enough for even that simple case. And you can imagine it will be much more difficult if you want to use some code introduced in other task.
Example 2
Task #34567 asks to implement Feedback page. This page is very similar to Contact Us page so it has similar css. We would like to reuse it. But how? It's not fair to say that #34567 depends on #12345. So it would be illogical to base issue-34567 on issue-12345. So what? Rewrite code manually? Copy-paste? Or still cherry-picks?
I don't see any reasonable solution for such issue.
