Version control system & # 8594; branch question

Iā€™m working on the next task, and suddenly I realize that I need to discuss some details with my boss in order to continue. I'll talk about this in a couple of days when I met my boss. Until then, I have to work on another task.

What's the correct way?

I see 2 options:

1) Copy the chapter revision from the repository to the new branch and run another task there. After I finish this - combine it with the trunk. Or maybe I need to first merge from the trunk into a branch and then merge back into the trunk?

2) Copy from working copy to new branch. Revert the trunk to the latest revision (before I started the task I need to discuss), switch to trunk and work on another issue, then end my current task on the branch and merge.

Please explain the correct path in detail as I am not an experienced VCS user. Thank you in advance.

+2


source to share


4 answers


The problem you are having is that you have started the changes in the trunk but want to commit it elsewhere. Most version control systems have no built-in behavior for this, which is unfortunate. In SVN, the best is:

  • Create a new branch from the outside
  • Make an SVN switch to switch your current working copy to that branch
  • You should now commit your local changes and be able to commit them to the new branch
  • After you commit them to the branch, do another jump to the outside line
  • Work on a new function on an outside line
  • After you discuss the details with your boss, merge them from the branch back into the trunk.


Hope it helps

+3


source


Indeed both options will work for you, and neither is more correct than the other; what will determine the simplest course of action is the difficulty required to merge the changes. In general, in svn, you want to avoid the merge if possible.

Usually this decision depends on your team culture; if your coworkers usually don't want pending / unapproved changes in the trunk, then it makes sense to push your changes to the branch and then merge after your boss has approved your code. Of course, if you're doing solo, it's up to you.



You do have a third option, which may or may not work depending on your situation, which is designed to handle two tasks at the same time on the backbone and separately for separate changes.

0


source


I will do the first option because I can keep my chest clean (works anytime). Since the feature you are talking about still needs to be confirmed by your boss. If the feature ends up being thrown away, your luggage will still be unaffected and other members of your team won't be confused by these changes.

0


source


We are creating a branch based on a release, not a task. So now everything that we are going to release in a few weeks is in section 5.1.1. The changes will be merged back into the trunk when they are posted for production.

-1


source







All Articles