I'm working in team with git and every time we try to merge code we have a tree conflict.
We're currently working with git flow and we usually start features from develop, when the task is finished one of us merges one feature into the other and then merge it into develop.
The problem is than every time we try to merge one feature into another we have a tree conflict in xcode and we don't know how to fix it.
The error message is: "The operation could not be performed because of one or more tree conflicts."
Please add .gitignore file if you have not added.
Refer link given below.
How to add .gitignore file into Xcode project
If it doesn't solve your problem, you can try to merge using terminal using given below command.
git mergetool
And then if there are any conflict then you can solve it.
I solved this by merging differently:
First I merged feature1 into develop, then I merged develop into feature2 and final feature2 in develop.
In this way there aren't tree conflicts.
This happened to me too. The problem was that the master branch had uncommited changes (unrelated to the changes in the other one). Switching to master and committing the changes allowed me to merge the feature branch back into master.
Try committing all the changes on all the branches and try the merge again after that.
I need to make a software release but I'm having issues with non consecutive changesets. I have almost 20 of them that need to pass from testing environment to production and I've already looked for many solutions.
My main problem is that I'm trying to keep Production branch clean so I want to merge all of those 20 changesets but push them to production as a single commit. I think it will also be easier to rollback if needed. Thing is that you cannot merge a changeset if it detects conflicts on another merge that is yet to be check-in.
Any ideas on how to do this?
Well you can't merge changeset directly. It's impossible. Could you create a independent branch for this situation.
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.
OK, I'm new to Mercurial and version control branching in general, so I may have a fundamental misunderstanding of what's going on here -- please be kind... ;)
We are a small development team (2 developers) working on a project, and we have a need to implement a fairly significant change that may take weeks or months. At the same time, the program is in daily use, so we have a need to make regular patches and fixes.
Because of the long-running nature of the significant change, I created a branch off the default branch (call it dev1). I will want to periodically merge the changes from the default branch into the dev1 branch, for reasons that don't need to be reiterated here. However, I do NOT want the changes from dev1 merged into the default branch until much later in the development.
I have tried several different ways to do this, but it always seems the merge affects both branches. After the merge, if I update to the default I now have changes from dev1 merged into the source.
Can I work on both branches using the same repository? If so, can someone please share the sequence of commands to use? If not, it seems to me I would not be able to push the dev1 branch up to the master repo until it was finished, and that just doesn't seem right.
We are running the latest TortoiseHg for Windows, and for the most part I love the graphical tool. However, I am perfectly willing to drop to the command line to do certain tasks when necessary.
Thanks for any help,
Dave
This depends on what sort of branch you've created.
If you have created a named branch, and are working in a single working directory, then you need to use one workflow, but if you have cloned your production repository, you need to use a different workflow.
Named branch workflow, single repo/working directory
In this case, you are using update to switch between the default branch and the dev1 feature branch.
When you want to work on the default branch, update to it, do your bug fixes, and commit those changes. Do not merge in changes from dev1 branch.
When you want to work on your dev1 branch, update to it, merge in your bug fixes from the default branch, work on your feature and commit when done.
If you are working on the dev1 branch and a colleague fixes a bug in default that you need, commit your work, fetch their changes, merge them in and then resume your work (there are shortcuts you can take here, but this way you can backout the merge if it gets messy)
Note: All of these assume that all of your changes are committed at the point you want to switch between dev1 and default branches.
The important thing to note is that you only get the changes from your dev1 branch in default when you merge them in. If you only merge default into dev1 then your feature branch will keep up to date with default so that when you are ready to deploy the feature into the default branch, you can do so with one simple merge operation.
Unnamed branch workflow using dev1 repo cloned from production repo
This workflow is similar, but allows you to work on the default and dev1 branches simultaneously, without having to update to switch between the two.
When you want to work on the default branch, use the repository where the tip is your production code. Do your bug fixes, and commit those changes just as you would normally.
When you want to work on your dev1 branch, use the repository where the tip is your dev1 feature branch. If there have been fixes in the default repository, pull in the changes and merge them into your clone, but do not push the merge changeset back. Only push your changeset back when you want to deploy you feature to production code. Once the changesets from default have been merged in, you can continue working on the feature.
If you are working on the dev1 branch and a colleague fixes a bug in default that you need, commit your work, fetch their changes from your shared repository into your default production clone, then pull those changes down into your dev1 feature clone, merge them in and then resume your work.
Again, the important thing to note is that you only get the changes from your dev1 branch in default when you push them up to your default production repository. If you only pull/merge default changesets into the dev1 clone then your feature branch will keep up to date with default so that when you are ready to deploy the feature into the default branch, you can do so with one simple push operation.
Yes, you can absolutely do this with Mercurial.
First, in case it isn't clear to you (it wasn't to me for some time), there are 3 types of 'branches' in Mercurial:
clone a repository
a 'named branch' (using the hg branch command)
an anonymous branch, which you can manage with bookmarks or just remembering the changeset
I'm guessing that you used the hg branch method. Be aware that this is often not what you want, because that branch name will live in the repo's history forever (well, there is the --close-branch option, but still...).
The essential workflow is:
update to dev branch with hg up devbranch
commit changes to dev branch
merge with main branch via hg merge default or just hg merge as desired
(repeat as desired)
And for working on the default branch:
update to default branch with hg up default
commit changes
(repeat as desired)
Do NOT do this:
update to default branch with hg up default
merge with dev branch with hg merge
I suspect that you are using the command hg merge without specifying a branch name. That will merge with any other head, which may or may not be what you want.
Edit: The above info is probably not your issue. Your issue is probably running a merge when your current branch is the default one.
You don't want to run hg merge from your default branch.
# bang on dev1
# more banging on dev1
# someone beats on default for a while
# update to dev1
hg up dev1
# bring in the changes from default
hg merge -r default
# validate successful merge
hg commit -m "merging"
The key is committing on dev1 when you bring changes over from default.
Note that I'm using named branches here.
This sentence:
After the merge, if I update to the default I now have changes from dev1 merged into the source.
tells me that you're doing something wrong. It is perfectly doable what you want to do, work on two branches in parallel, and merge from one to the other, without influencing both.
It is important to know that the merge is a directional merge. You merge from one branch to the other, and when you initiate the merge, you should be on the to-branch.
directional in the sense that the direction plays a role in the outcome. For the actual contents of the file, it doesn't matter which direction you merge, but the new merge-changeset you commit will be on the branch you was on when you initiated the merge (unless you override.)
So, update to the head of dev1 first, then merge with default, and after committing, you should have a new changeset on the dev1 branch, but default should be left undisturbed.
This is more of a tip than an answer, but...
I use this workflow a lot. I find the Transplant extension very useful for named branch workflows. TortoiseHg supports it, so you can enable it in the TortoiseHg options. It lets you cherry-pick from other branches, which is very useful - especially if you regularly commit to the wrong branch.
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".