How can we maintain forking release branches of day to day release pipeline?

[Srinivasagupta Maram]

Now a days most of the applications looking for day to day releases. Especially microservices looking for this kind of releases for hot fixes and features. What I just observed that for every requirement or hot-fix better maintenance is creating separate branches is the best way. But here if any requirement was started in early days we are maintaining seperate branch for that. But on top of that if we need do any hot fix we are going with some parallel branch and doing release that. In this cases merging these both is manual process. If we have auto update forking between release branch and feature branches, it might help full for development activities. Did we have any feature already like this?

[Mike Birtwistle]

Also, a tip I've learned the hard way over time, is to never, ever commit work directly onto a shared branch that I need to regularly 'pull' in order to pick up changes from my team. I always create my own personal named local working version of that branch, and commit to that.  When I need to pick up the latest changes from the shared branch, I commit my work-in-progress to my personal branch, switch back to the shared branch and easily pull the shared branch with no conflicts during the pull process (because I never committed onto the branch I'm trying to pull).  I now have a local copy of the latest changes on my machine, so I can easily work out how to merge latest shared into mine, and then mine into shared.

[Mike Birtwistle]

I think your real problem is long-lived branches getting 'stale'.  Try to break 'big feature' work down into smaller, releasable phases so you can merge small and often.  To encourage this methodology in your team, use pull requests with peer reviews and work towards having automated pull request build and test routines in place. These features will give your team the confidence to merge smaller units of work into 'master' more often, and help to reduce the tendency to work on long-lived feature branches with their scary big-bang release impacts.

[Srinivasagupta Maram]

Here my concern also conflict only. If we have any update like sync failure or something like need to take pull while doing development of feature, we may get less damage of productivity.

Since we are taking care about merging at the time of release, it is causing issues if we have more number of conflicts.

Thank you.

[Deleted user]

No, it actually doesn't exist. Think about conflicts, if there is one when auto-updating  how would it be resolved?

To have a good git workflow, used by many developers, you can use git-flow, it helps you a lot with correct merging, starting branch, etc...