I have spent a long time looking for an answer regarding merge conflicts with project.pbxproj files. My merge conflicts mainly occur with Cocoapods. It seems that if I add a pod on a branch, then try to merge it into another, many many merge conflict arise in the project.pbxproj file of my Pods project. I would simply go trough and fix these conflicts manually, but there are way to many for this to be reasonable. Has anyone else encountered this problem and found a reasonable solution. This issue has plagued me for sometime now and I am only asking this question as a last resort. After creating a couple of new features on separate branches, having this much trouble including them into my project is very frustrating. Any help would be very much appreciated.
As long as you're not making changes, which you probably shouldn't be, to the Pods.xcodeproj file, then the source of truth is always what is generated with pod install. Therefore if there are many conflicts you can just delete the project and regenerate it.
I've run into this on a fairly regular basis. I have a recipe that works most of the time. We use Git-flow, so are typically trying to merge feature branches into develop. Memory being what it is, often the first time we notice this is when GitHub warns of a conflict.
Commit (or stash) all outstanding work on your local feature branch.
Run pod deintegrate (docs here)
Commit the branch. It’s temporarily in an unusable state. This will be resolved momentarily.
Switch to the latest develop
Again, run pod deintegrate
Commit changes to develop. Don’t push these changes up to origin. This commit will be deleted shortly.
Switch back to your working branch.
Merge in your local develop. Hopefully this will be conflict free.
Run pod install, run the apps and check that everything works as expected.
Commit the merge. Delete the local develop commit (i.e. git reset to origin)
Push working branch changes.
You may also want to consider using a hook to prevent pushes of integrated projects. This puts the onus on the developer to pod deintegrate before pushing changes up (and also requires other developers to pod deintegrate before merging from develop) but does remove one potential source of conflicts if using a cloud repo provider that manages your workflow like GitHub.
It's also worth splitting out file-add operations into their own commit to reduce the noise.
Following by this guild: https://github.com/CocoaPods/CocoaPods/issues/3093
For CocoaPods to say that message, the project will have <<<<<<<, >>>>>>> or ======= on a line indicating it has a conflict which hasn't been resolved.
It is possible that there is still the conflict markers and the file is still in a conflict (git only says it's resolved because it was told it has been resolved regardless of the conflict markers).
You can find them in your file by running the following:
grep -E '<<<<<<<|>>>>>>>|=======' /path/to/project/project.pbxproj
Related
Looking for a general suggestion as I occasionally run into errors in branches in my iOS git efforts. I create branches from dev to isolate changes as per usual. I start out with everything tracked, including pods. I commit often from Xcode to remote, and only use SourceTree to manage higher level stuff like branches, merges etc.
BUT.. every so often, when i return to a branch and compile before restarting efforts, i see "no such file or directory" errors for a file or three from other branches. I just don't see what i am doing wrong, unless staging every file is my mistake.
Is this enough for somebody to offer advice? If not, and if the question is too general, feel free to wipe it, thank you.
Just re-based the repository Xcode project to an older version that used to work fine. (in an attempt to add back support for iOS 7)
Now - one of the frameworks is through a "file not found" error for the header files. But, the files are still there. Everything used to build just fine on this version of the project (3-4 months ago), everything builds fine on current, new version of the repo. So, why the trouble here?
Rebasing is a concept where in you change the entire history of your commits. You should only rebase a branch onto its parent branch or it might create issues.
Rebasing repositions the head and then applies all commits made after the point of branching as patches, one patch at a time. Each patch is applied and resolved for conflicts if any. You must do this until all patches are applied. If you are not careful in this process, its easy to accidentally lose code or entire files or frameworks that you have added.
Please go through the git rebase documentation for more details.
Hope this helps :)
I have found that git rebase can be a bit of a nightmare when using XCode. From my experience, the best solution to making sure a branch is up-to-date with master is by doing the following (instead of rebasing):
While on your branch you created off master:
Select Source Control on the XCode Navigation Bar -> Pull -> Pull remote changes, select "origin/master" and select "Pull"
I've had the most success doing things this way vs. the pain of fixing a rebase gone wild.
Try these steps hope this will help you.
1)target of project -> Build Phases -> Compile Sources ->
2)delete the [found filename that cause the error in program].m
3)Add it back again in you project.
4)Clean Your iOS project And then Build Again.
I want to know which files created by CocoaPods in a given iOS project should be checked into version control. What makes most sense to include and ignore? Should I just add the Podfile? Or should I add the entire pods directory?
This is an ongoing debate even with the CocoaPods core team. https://github.com/CocoaPods/guides.cocoapods.org/issues/3
At some point someone felt that it should be ignored enough to get it into Github's gitignore template for Objective-C.
Some good points were brought up in the linked debate above about longevity of the project where if you check in your pods directory in the future other developers should always be able to build the source regardless of the state of CocoaPods or the specs repository without any dependency on the command line too. But I could see you having this same issues with Git submodules since the remote repositories could be deleted in the future as well. I think this comes down to your preference. Personally I don't like having updates to external dependencies directly in my source control history.
I can't figure out the best way to do this and it has happened a few times where I mess myself up that it'd be nice to know a possible good way for this. On master, I have our main project. We finally got approved to use ARC in iOS and I created a new branch for that to not mess with the main working master branch. I also took the time to delete some unneeded files in my ARCBranch. What I want to do is use this branch for development for the next release. I'd like to pull in the changes from master to the ARCBranch. So I switched to ARCBranch, and did
git pull origin master
I got conflicts, some which were straightforward because I could see the code, others being changes in the pbxproj file where I cannot tell what's what. I did see
<<< HEAD ==== >>>. I can't tell what I need to do here. I can't open it in Xcode, only a text editor. I tried just deleting those <<< === >>> characters since I saw one person on SO say that you typically want both changes and that you could always do that. This didn't work for me. I was wondering if there is a better way to do this change. Maybe somewhere where I can see each change by change happen? Thanks.
Instead, you could try
git rebase master
This would apply the changes commit by commit. If there are conflicts, it would stop there, so that you can resolve them and do
git rebase --continue
to finish applying all the patches.
It failed to auto merge so it marks the conflicting blocks of code and leaves them both so you can decide and remove one yourself.
My question is, is there a way to mark a specific commit(s) so that either it won't be merged into another branch, or it will be ignored when I issue a "git push" or fetch from another repository?
My understanding is that you can cherry-pick specific commits to merge into the current branch; is there some way to mark a commit as 'local' to a specific machine/repository/branch?
The problem this question grew out of, I am currently solving a different way. Specifically, there is a specific version of sqlite3-ruby (1.2.5) that I require to work on a Rails application on one OSX machine to which I don't have root access. Right now I've made the commit to specify the version in the Gemfile on a local branch called "mac-bundle", and my plan is simply to switch to that branch and merge necessary changes before I run bundle if I need to install a ruby gem.
Which is a minor but live-withable annoyance. It seems possible that a similar situation might arise where the same workaround won't be quite as acceptable, so I thought I would ask for ideas on a different solution.
(Question similar to this one: Committing Machine Specific Configuration Files , and my current solution is similar to Greg Hewgill's answer.)
No, there is not a way to mark a commit as "not to be included in merges". Using separate branches is pretty much as close as it gets.
No, you can't. You can however "fake a commit" on a particular branch.
To do that, you can
git merge OtherBranchName --no-commit
This applies the changes and leaves it in the index for you to take action. Then, you can manually remove the changes applied and commit.
Git then thinks that commit has been applied on this branch, and you both live happily thereafter.
However, this might be ok as a one off, specifically to deal with configuration files. But you should not make this a general practice.