I merged one of my branches into master through Xcode. As soon as I did, all of my files in the project navigator disappeared.
Git in terminal has run me through loops trying to revert back to a previous commit.
I am relatively new to git, so could someone please guide me through the correct process of A) retrieving my files, and (if someone feels like being incredibly helpful) B) properly adding/merging a branch into the master branch?
EDIT
The .xcodeproj file is still intact and usable with the correct files, it is the .xcworkspace file I have been using (as a result of cocoa pods) that no longer contains any of the appropriate files.
So within the .xcworkspace file, I can no longer access the scheme or find any of the files or utilize source control.
Related
I have problems with git using Xcode for my iOS project.
I'm using CocoaPods for my dependencies. Everytime I click "commit" I have some modified files listed (mainly from Pods directory) although I added Pods to my .gitignore and I did not make any changes to these files since the last commit.
Despite that they are always marked as "M" and ticked off even seconds after the last commit.
It is worth noting that I don't see any visible changes in the comparison view in those files.
Can someone please explain what happens and how to fix it?
I am using SourceTree as a git client.
A while ago, I had a major problem with my project and my git, so I had to reactivate a copy of my workspace from an external source. For that purpose I had created a complete new repository. Commiting to that now.
Today I've noticed, that most of my files appear as "modified" in Xcode. Even after commit and push (with SourceTree).
Source Control shows my two branches, what is correct:
And the History shows perfectly all the commits:
My feeling tells me, that in the background the old repository information is still present and does this bug. How do I handle this? Help is very appreciated.
Edit:
git diff --ws-error-highlight=new,old Output
Close Xcode. If you can avoid it, don't reopen Xcode :-) If it's an absolute must, reopen Xcode. The M markers should be gone.
This worked for me:
Delete derived data folder(Steps: Click Xcode on top left -> Preferences -> Locations -> Click on the right arrow below Derived Data and that will you take you to the Derived Data folder in Finder. Delete it)
Quit Xcode (Don't just close the project)
Reopen Xcode
Check if the nature of the diff is related to eol (end of lines).
See "git diff - show me line ending changes?", like:
git diff --ws-error-highlight=new,old
If that is the case, try first:
git config --global core.autocrlf false
Then try again to clone your repo, and see if XCode still display those differences.
In your case, this is not about eol, but about an update done in your files.
Check for any .gitattributes file: is there a smudge directive in those files (which would explain an automatic process taking place on checkout)
See Keyword expansion for an example of smudge script.
Something seems to update JTAppleCalendar to its latest relase (6.0.1 from 7 days ago)
My feeling tells me, that in the background the old repository information is still present and does this bug.
Simply try, in command-line, to clone again that repo (in a brand new local path) and check if the issue persists in that new cloned repo.
to the JTAppleCalendar, I have changed from 6.0.0 to 6.0.1 manually. around 7 days ago. when the new xcode 8.0.1 arrived
In that case, all those files should be listed as modified: that is what Git does.
I am working on a Swift based XCode project that is synced with Git based master repository. One of my team member has added few files, to the master which I have pulled.
I find those files in my project directory, but not in my project. When I am manually trying to add these files to the project, in that case, I am getting Modify tag on my project, then I am unable to pull new changes from master.
This is very annoying. How do I take care of this.
Also, how do we make sure as a team that everyone of us is working separately on different module, and make surely everyone is able to commit/pull each other's changes.
The project folder with M tag is prohibiting us from doing so.
Edit 1
I have followed steps for this as well
git rm -r --cached ProjectName.xcodeproj
git commit -m "Removed file that shouldn't be tracked"
Even after doing this,
I had made changes in File1.swift, with my team member's changes in File2.swift
He had already committed it, I wanted to pull those changes, however due to changes in File1.swift I was unable to pull it.In order to make it work, I had to discard changes in File1.swift and then only I was able to pull those changes. If this is so, then it is defeating the purpose of using git
Xcode project files
The Xcode project file, or to be more precise, the pbxproj file inside the xcodeproj container keeps track of all files (among other things). Unlike Eclipse, Xcode does not monitor your source/project folder for changes thus does not update the list of files which can lead to inconsistencies after a merge.
Merge conflicts
If your team member adds or removes a file in his local copy of the repository and pushes his changes to the server, he basically overwrittes the pbxproj and therefore updates the list of files of the Xcode project. If you pull those changes there are two possible scenarios:
Git can merge the changes automatically which usually means it will keep your copy of the pbxproj file without the updated file references.
Git cannot merge the changes and therefore indicates a merge conflict that you need to resolve yourself. Depending on the differences and amount of changes these merge conflicts can be pretty annoying to resolve. Sometimes it might be easier to just delete your copy of the pbxproj file, use the one from the server and reapply your local changes, e.g., add file references.
In both cases you might need to compare your pbxproj file against the one from the server and merge things by hand. And yes, your project file will be marked with an M (for modified) which is perfectly fine. Just commit your changes and you are good to go again.
One more thing: Whenever you want to pull changes from the git server you can either stash your changes (git stash) or commit them.
Avoiding merge conflicts
In case you want to avoid merge conflicts in the future, I recommend having a look at the following tools.
Cocoapods
Cocoapods can be used to modularise your project into smaller pieces by creating private Pods. The benefit of this technique: You do not have to keep track of newly added or removed files. Just run pod update and you are up and running again. There are several blog posts that describe this technique in detail, e.g., here
phoenx
At my former company we had a pretty huge codebase and ran into some trouble when using Cocoapods. Therefore, we have developed our own meta-build system called phoenx. Phoenx can generate Xcode project and workspace setups of arbitrary complexity. It uses metadata files (something like Podfiles and Podspecs) to generate the projects etc. . Build settings will be stored in xcconfig files. At the moment it does not provide any setup tool so you have to invest a bit of time to write the xcconfig and metadata files by hand. We are working on a more convenient way to use it though. If you want to give it a try you can install it via sudo gem install phoenx. Documentation is available on GitHub.
Hope that helps!
My project had several folders that accidentally got added to my GitHub repository. I could delete them (one file at a time) from the GitHub website but that is tedious for a large number of files. I tried using git on the command line but it was conflicting with the Xcode source control updates. I would just like to do it graphically in Xcode if possible.
The closest Xcode question that I could find was this one, but it was about removing source control altogether, which I don't want to do.
I struggled with this for quite some time but it turned out to be fairly easy. I am sharing my answer below.
As long as you have your project already connected to a remote GitHub repository, all you have to do is use Finder to delete the files or folders.
Then go to Source Control and choose Commit and after that Push.
This will delete the files from your GitHub repository without you having to use the command line.
I have a large (hundreds of files), horribly disorganized (on the file system that is) Xcode project. I want to move a bunch of files into different folders. I want git to track the move operations, and I want my Xcode project to track the moves as well (just keeping the references intact is enough; I don't need Xcode to rearrange its internal group structure, etc.)
If I drag things around in the Finder, both Xcode and git are in the dark. I have faith that git will figure things out by content when the time comes, but I also notice that there's a difference in the output of git status between doing a git mv and moving the file in the Finder, then adding the deletion and addition operations separately, so I'm assuming there's some difference (even if that difference doesn't end up getting encoded into the content of the commit.) Xcode, on the other hand, is hopeless in the face of this. (You have to manually re-find every single file.)
If I use git mv from the command line, git tracks the move, but I still have to manually reconnect each reference in Xcode (or tear them all out and reimport everything, which is a pain in the ass because many of these files have custom build flags associated with them.)
It appears that there simply isn't a way to cause a file system move from within Xcode.
I've found zerg-xcode and a plug-in for it that claims to sync the file system to mirror the Xcode group structure, but I've not been able to google up anything that goes the other way. I just want a way to move files on the file system and have the two other things (git and Xcode) to keep track of the files across the moves. Is this too much to ask? So far it seems the answer is, "yes".
Yes, I've seen Moving Files into a Real Folder in Xcode I'm asking whether someone's written a script or something that makes this less painful.
Actually, by design, Git doesn't track moves. Git is only about content. If any Git tool tells you there was a move (like git log --follow, it's something that was guessed from content, not from metadata).
So you won't lose information if you move files around with another tool then git add the whole folder.