I am using TFS2012 express. I have a project which has two branches.These two branches have similar file and code. Actually one is release code(one which i gave to customers) and another is testing code. I always change code in testing code branch. So sometime i need to checkin this changes to both the branch. Also some changes i don't want to check-in to both and only to testing code branch. So how i can do it in tfs? Problem is how to checkin only certain changes to both branch and some changes to only one branch?
You can always check in the changes to testing branch. If you need certain changes in the release branch as well, you can use Merge command to do that.
When you do Merge, you can choose "Selected change sets" instead of All changes. When resolving conflicts in mergetool, you can choose/make the changes you like in the result panel at the bottom which is editable.
Related
The current workflow for our developers is
Create a new branch from develop for each bug
Make your changes, and commit them
Create a Pull request
The issue :
I am working on bug 1, branch name develop_bug1 . I commit my changes in the file file1.jsp and create a PR
I now start working on bug 2, branch name develop_bug2. I find out that changes need to be made in the same file file1.jsp as bug 1. When I checkout develop_bug2, my changes from develop_bug1 aren't present.
What if I finish my changes for bug 2 and commit and create a PR? Will it overwrite changes for bug 1?
Not sure where to start
Changes on the two branches will not be present in the other branch or the develop branch until the two bug branches are merged. They are entirely separate ‘copies’ of the code.
Because both involve changes to the same file (file1.jsp) there are going to be so-called merge conflicts, which need to be managed.
Let’s assume that develop_bug1 is to be merged back into develop first (either because it is more urgent or because is has less changes).
Step 1: Merge develop_bug1 into develop. There will be no conflicts.
Step 2: Merge develop into develop_bug2. This is sometimes called rebasing. There will be merge conflicts which you will need to resolve. Your IDE will help you deal with the conflicts by selecting which version of each change to accept.
Step 3: Merge the updated develop_bug2 (which now includes changes originating in develop_bug1) into develop. There will be no conflicts.
If none of the PRs gets merged, then there are no conflicts in both of two branches.
If one of the PRs gets merged, then the second PR will get conflicts, we should resolve the conflicts first, push to remote, and then the second PR could be merged.
PS: always pull the lasted code into local branch before we raising a PR.
I have been developing a feature for my app in Xcode. I use the master-branch as my stable/production-ready branch. When i work on a feature i start a feature-branch. This particular feature branch I have been using has had a lot of significant commits (30+ commits) and now when i try to merge it into my master-branch Xcode tells me there has been a conflict with various files and the merge is unable to be performed. There is no option to resolve the conflicts.
I am using Xcode 8.0. At this point the feature-branch is far ahead of the master-branch and is production ready. I would like to begin working on new features but i don't want to make a mess by creating more branches off of the current feature branch. The only thing I can think of is to just completely replace the master-branch with my feature-branch but is this even possible? If so then how?
I have been unable to find anything in Xcode, Apple documentation or on stack. Thanks for any advice!
What you should do here is merge your master-branch into your feature-branch. Fix your conflicts. Test, make sure it works. When you're convinced all is good, merge feature-branch back into master-branch.
During this time, you can still work in master-branch as needed. But keep in mind more conflicts could arise. And in that case, I'd also just do master-branch -> feature-branch -> master-branch where the "->" represents doing a merge.
For conflicts, I actually don't use Xcode to resolve, but there are numerous resources out there to indicate how to do this.
I had a similar situation, but Source Control in Xcode wouldn't let me merge branches due to "tree conflicts". It just hung. Good thing I had a backup, cause I could no longer open the project.
After restoring the project from my backup, I did the following to replace the Master branch with my Development branch.
In Xcode I went to Source Control-> Working Copies and selected my Development branch as the working copy.
Under Source Control, I did a Commit for all my pending changes
In Source Control in the Working Copies section, I hovered over the the Development branch to expand the menu to the right and selected Configure project name
At the top of the Configure window, I selected Branches
I selected the Master branch and clicked on the - sign at the bottom and confirmed that I wanted to delete it.
Went back to Source Control, hovered over the Development branch in the Working Copies section and selected New Branch from the menu that expanded to the right.
Named the new branch "Master". This made Master the current branch.
When back to Source Control and changed the current branch back to my Development branch.
In our org, we work on many feature branches under the same project.However we face many issues when merging code where people working in other branches don't know the changes made.Due to concurrency issues,sometimes it breaks in production. Can anyone recommend a tool for TFS similar to what sourcetree does for github?. We face many concurreny issues as there are many people working on the same project with many branches. We would like to notify use if any merges have been made in the main branch or the feature branch.
To get alert when there is a merge to main branch, you can create a Checkin Alert "A file is checked in under a specified path" to make "Server item" "Under" "$/TeamProject/MainBranch". In this way, when there is checkin on MainBranch or FeatureBranch, an alert will be sent out.
By the way, to use Feature isolation branching strategy, the considerations should be include:
Each feature branch should be a full child branch of the main branch.
Keep the life of your feature development short, and merge with
main frequently.
Feature branches should build and run Build Verification Tests
the same way as main.
Merge frequently from main to feature branches if changes are
happening directly on main.
Merge from feature to main based on some objective team criteria.
You can get more information about merge and branch at website:
https://vsarbranchingguide.codeplex.com/releases
When we create a branch from our main trunk in TFS we also change the web.config to point to different databases, web services, etc. When we make a bug fix we do it in the release branch and merge back to the trunk. I'd like a way to click on the root node for the branch and merge the whole thing back to the trunk except for the web.config which has release-branch-specific settings which should not be merged back.
Is there a way to break the branch link for this file or is there some other method to permanently exclude the release web.config when merging back to the trunk?
You have two options to do this today:
Use "tf merge /discard". When performed on a file across branches it tells the merge engine that you do not want this specific change merged between these two branches. The downside of this approach is that you will need to run tf merge /discard each time you check in a change to the file. Here is what the syntax would look like if you wanted to discard the change from moving from releasebranch to trunk:
tf merge $/releasebranch/.../web.config $/trunk/.../web.config /discard
The second option is to cloak the web.config in the target branch when you are performing the merge. That is if you are merging into trunk, cloak the web.config file in the trunk branch in your workspace. When you perform the merge, since the target of the merge is cloaked, the change will not flow over the branch. The downside here of course is that you have to remember to perform the merges in workspaces with this configuration each time.
Bonus: I created this uservoice suggestion to improve this experience. Vote for it if this is something you would like to see improved.
For personal projects I use Git for SCM, but at work we use TFS. One thing that I like about Git is that it allows a person to easily squash all the changes made in a branch when pulling the changes back into the master branch.
The benefit of this is that if their is anything wrong with the changes they can easily be removed be reverting back to the version before the merge even if no tag was created.
Is this. or the equivalent possible in TFS? Is this where shelving changes fits into the equation?
Thanks.
Performing a merge in TFS results in a single commit; all of the changes from the source branch get rolled up into one changeset pended against the target branch. So as far as I understand your question, the answer is "yes".