简体   繁体   中英

Is adding to a branch after its pull request has been merged bad?

I'm working on a project where we branch off of develop for each feature and once the work is done a pull request is made as usual.

I'm wondering if later on I find I want to make some changes to how I implemented the feature is it better to just make a new branch or, since it's still dealing with that feature, to checkout that branch, merge with develop, make changes and then resubmit a pull request? What is best practice in this situation?

I would just make a new branch. The more recent your branch point, the fewer conflicts you'll have to deal with when merging.

Technically, as long as you merge master on top of the feature branch before changing anything, it is not a problem re-using a branch. However, your project seems to follow the "one branch-per-issue model" and that's why it may be "bad", and also why the question may out of scope for this page.

Case 1: Faulty implementation

Although it should not happen since you have done tests on the code, test in real-world applications, and another person checked all that during after your pull-request, there might be still something wrong. I am personally fine with re-open a ticket and its according branch.

Case 2: The feature might be enhanced

However, if the feature was doing his job and you soleley want to optimise it, that is a new feature. Depending on the tools you're using in the whole development process, you simply want to seperate this new feature (and its discussions etc) from the old one to measure the work/outcome etc properly.

If that is "bad" or not is up to your project, used tools, conventions, etc and has to be answered individually.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM