Clever Geek Handbook

Git Problems with branching and merging workflows. How do you do this?

This is our development workflow:

  • A developer is working on an issue in a new topic branch.
  • Once he's done, he nudges the branch for review.
  • I am merging a branch into a development branch and pushing it upstream on a staging server.
  • The client reviews the changes and approves / rejects it.

My problem is in steps 3 and 4. The client only has access to the staging server, so in order for him to see the changes, I need to merge the theme branch into a development branch and push it to the staging server and I usually don't merge just one branch, but on average 3 - 4.

If a client rejects the changes and needs further modifications, the developer fixes the issues in one theme branch and I have to regenerate in development.

By merging the topic branch several times in development, I lose track of this issue in history. (sometimes also leading to conflicts)

Is this a "healthy" development process? What are your suggestions, improvements?

+3


source to share


2 answers


If a client rejects the changes and needs further modifications, the developer fixes the issues in one theme branch and I have to regenerate in development.

I would rather go back (as in git revert

) a rejected change on the development branch and wait for the developer's fix.
using git revert i only add new commits instead of changing history (with rebase or git reset

)



So the next commit (of the same feature) should be easily merged into the development branch.

+2


source


Just put in a staging branch that is dirty and no one is allowed to branch it.

  • Make sure the staging process handles history rewrites. If your staging server pulls from the central repo, replace pull with fetch

    andreset --hard origin/branch

  • Whenever you want the client to review the changes, just use your process before - merge it and, if needed, change it, remerge.
  • Combine develop

    from time to time to make sure you have all of its changes. If you have no feedback (= staging

    should be in sync with develop

    ), reset staging

    to develop

    instead ( git checkout staging

    ; git reset --hard develop

    )
  • As the setup is supposed to be messy, you can always rewrite like crazy, like just going back a few steps ( git reset --hard HEAD~4

    ) with no consequences if the change breaks something, etc.
  • Only merge your changes after the client has approved them.


This way you don't have to worry about creating a nice story in the process when you don't really care about the story (showing things to clients) and your branch develop

gets a very clean story.

If you are worried about having to resolve merge conflicts multiple times check out git s reerere feauture

+1


source






More articles:


All Articles