3

I am a member of a small team which is part of a larger team of developers working with Git. We (the larger team) have a main branch in a central repository into which we commit our work for the next release (let's call it 1.0). The smaller team has been tasked with developing a feature (upgrading an existing one, actually) that will not make it into release 1.0, but a later release (1.1). I'm wondering how to manage the development of this feature in Git. I have looked at several Git workflows but could not find one that really fits.

First, we're working on this feature as a team, so I thought it would be appropriate to maintain a remote feature branch on the central repository which we'll all push to and then merge with the main branch when the feature is done. But releasing 1.0 could take a few months and that means we'll be isolated from the main branch for a long time, which would probably make merging back into main very hard. Ideally I would want to pull changes from main into our feature branch daily/weekly (as to deal with conflicts early on and not in one go after several months) but I've read this is not recommended in Git (to my understanding, merging from main to a feature branch or rebasing a public branch is discouraged).

I've seen a similar question but the accepted answer just says to not work this way. As I am not the one deciding our releases, this is not a solution that works for me. Relating to this, even if I think the code is stable I cannot commit it to main, because QA doesn't have time to check the feature for the 1.0 release and the code changes might introduce a bug. I know about automatic regression testing and continuous integration and I'm pushing hard for both, but right now these things aren't possible.

What is the best way to handle this?

Improve this question
3
  • 1
    Is upgrading that existing feature going to be a big-bang update? So at once you switch over to the new implementation and you go live? Isn't it possible to do that upgrading / refactoring in smaller pieces which you just merge into the main branch? That's essentially what the most simple way is. The risk you run with your long feature branch is, next to merge issues, that you will not have your code running in production for a very long time. Let's say you encounter performance issues after going live you have to search through months of work to find the issue.
    – Luc Franken
    Aug 17, 2016 at 11:25
  • The question you linked does not say "don't do this, choose a different release strategy". It says "don't manage this scenario by git branchs, instead manage this by utilizing feature toggles". Might be an option for you?
    – Doc Brown
    Aug 20, 2016 at 20:00
  • You're both right. The problem is that without automated regression tests and with QA not checking the feature before the next release, changing the code (incrementally, or using feature toggles) is risky and I would rather deal with a nasty merge than run the risk of bugs in production (especially for a feature that was not supposed to change in the released version).
    – Michal Tenenberg
    Aug 22, 2016 at 8:47

2 Answers 2

Reset to default
1

What you've left out of your description is if the new feature demands serious overhauling of the existing code. That would make it a 2.0 rather than a 1.1. So I'm going to assume you're not doing that.

The smartest way to do this is continually update the feature branch with updates to the main branch. This will catch merging problems early and 1.1 won't touch the main branch until it's ready. The main branch will continue to receive minor updates while 1.1 is developed. The feature branch (1.1) will as well.

Not doing this doesn't avoid these problems. It just turns them into one huge pile of problems that you keep putting off dealing with until the merge. Better to deal with them early as they come up.

Improve this answer
1
  • 1
    You are right in assuming it's not a serious overhauling of existing code. Could you specify how to technically do the update you mention? That's the piece I'm missing right now.
    – Michal Tenenberg
    Aug 17, 2016 at 10:27
-1

While working in feature branches it is a good practice to keep up-to-date with master.

This can be achieved by two different methods:

  • merge in the latest master git merge master

  • rebase against the latest master git rebase master

Most often I find rebase is the best way because when there are conflicts they are presented in the most easy way to fix.

Frequently rebasing against the updated master is a common practice in the various shops I've worked in.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.