I've got a pretty simple repository made up of a frontend folder in which I have a react app, and a backend folder that is mostly empty for now.
Every few minutes, regardless of whether or not I make any changes to any files, some node_modules file will pop up in GitHub desktop showing a difference.
screenshot of my github desktop
Do I need to add node_modules to my .gitignore file?
This didn't happen before, I don't know what happened to trigger this. I add the changes because I assume it's an important node_modules update but then it happens again a few minutes later.
I'd like to understand why this is happening and how I can prevent it from happening as it makes my commit history impossible to read.
Simplest solution would be to gitignore node modules like so...
/node_modules
Unless you have a specific reason to track changes to npm?
It's usually better to install fresh packages via npm install when setting up on a different enviroment/device.
Related
I have a problem with Gitlens extension. Firstly, Gitlens or Git History extension is working fine on any other project except the this Laravel project. My problem is, can`t see the file history or line history in this project.
On the other hand, there is no problem in the git log (Git History Extension) as seen in screenshot;
But I can't compare any files with their any version (every commit seems like in the ss). I have no idea what the problem is about.
Lastly, I don't think the problem is about extension settings because other projects do not have this problem. Is there a any chance to fix this issue without resetting git history?
I am answering after 3 months, maybe it works for someone. As I mentioned in the title, surely there is no problem about extension settings for this specific project. The problem is just about git files. Maybe, I damaged some git files while moving the project on my desktop :)
So, there is no chance to fix this issue without resetting git history or starting fresh with git, if you`re having the same problem.
Do not play with git files, it`s no joke!
I've got a similar issue. My problem is in using symbolic links for folders.
I have this folder symlink for my repos.
C:\>dir
Directory of C:\
27.09.2018 21:07 <JUNCTION> repos [C:\Users\Qwerty\repos]
(GitLens v11)
The top editor is opened via C:\repos
The bottom editor via C:\Users\Qwerty\repos
You can see that some git features still work (yellow), but others don't.
However, this is very strange, because in my other repos, I have never observed such issues.
Also notice below that it is still possible to invoke the same action via a git lens popup and then it is possible to use the Prev Next Revision buttons.
Anyway, after more testing, I actually observe the same thing in my other repos. I assume that something must have changed between versions as I only observe these issues for last maybe 2-3 months. I even submitted a ticket that GitLens stopped working in v12.0.0 and later versions https://github.com/gitkraken/vscode-gitlens/issues/1979
The buttons completely disappeared and even the commit information
v11
v12
And Now actually, after having reopened my repo via original path and after updating GitLens back to v12.0.6 I see that it is working properly!
Bottom editor is opened via C:\repos symlink.
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!
I am working on laravel 5.1 project. I have updated few files for customization e.g. vendor/laravel/framework/src/Illuminate/Foundation/Auth/AuthenticatesUsers.php file. It needed to install new package so I had modified composer.json and run command 'composer update' and package was installed but all the code I had updated in AuthenticatesUsers.php file was replaced with original.
How to prevent this over-writing while updating composer?
You are not supposed to edit files in the vendor folder if you also want to use Composer to easily update your dependencies. Editing files of external packages effectively means you are forking that project and maintain it yourself. This either means you only apply your change once and then stop all further development, or you constantly have to check for updates of the original package and merge their changes with your changes.
I am pretty sure there are ways to solve the underlying problem with adding changes to existing files, but your current question suffers from the XY problem - you want to add a change to Laravel but don't know how to do properly, find that editing may solve the problem, but now need to prevent overwriting that file, and ask about preventing that overwriting - instead of asking how to add change to Laravel classes.
A nice and clean solution would be to fork the repository and add it to packagist. Then simply change the composer dependency with your version of improved (so to speak) laravel's source code.
I can create a repo and use GitHub / BitBucket fine for my own projects. I have had problems when collaborating with other developers or trying to fork a project on GitHub.
I am aware of other answers like Best practices for git repositories on open source projects but there are OSX / Xcode specific problems I want to know how to solve.
.DS_Store files can be a pain. You can use .gitignore to prevent, but what happens if they have already been included, or another developer adds them back in through a clumsy git command?
The .xcodeproj will have changes to the directory names and developer profiles for the other person. What's the best way to do merges or to avoid conflicts?
If I have forked or pulled from a github project, how can I clean up these issues and also minimise merge conflicts for the maintainer?
If people have an example .gitignore created for Xcode, or scripts they use to initialise their repos then that would be great!
Put .DS_Store in .gitignore. Then, if you haven't already, add .gitignore to the repo. (You should not ignore .gitignore.) Now all developers will ignore .DS_Store files. If any were added to the repo erroneously before you put .DS_Store in .gitignore, you can now remove them (in a commit) and they should stay out.
The xcodeproj is a directory. The only file in this directory that must be in the repository is the project.pbxproj file. I generally ignore all of the others by putting these lines in my .gitignore:
*.xcuserstate
project.xcworkspace/
xcuserdata/
You should avoid putting absolute paths in your build settings. Use relative paths.
Your Debug and Release builds should use iPhone Developer as the code signing identity, so that Xcode will automatically select the local developer's profile. When you want to create an IPA (for distribution), Xcode will offer to re-sign it with a different identity, at which point you can choose your distribution profile if you need to.
If you're trying to use a project from github that has made these mistakes, you can try to get the maintainer to fix them, or you can make sure you don't touch the .DS_Store files and the code signing identities in the same commits that you want to send upstream.
For the 2nd issue regarding the .xcodeproj and merge conflicts.
Using a .gitattributes file to specify that merge conflicts for all .pbxproj files should be handled using the merge=union strategy, which should mean that Git knows to merge in the changes from both sides of the conflict, taking the upstream changes first.
This article explains it in a bit more depth
I'll try one by one:
I. You need to use git filter-branch only if you need to remove the files from your history completely. If those files do not contain any credit card information, then i think the following should be enough:
git rm --cached .DS_Store
git commit -m "{Your message}"
then add this file to .gitignore and commit it.
This will commit the removal of the file from the repository but will keep the file in working directory. If you push it though and then somebody else will pull this commit, they might have their file removed, so you MUST communicate this.
By committing .gitignore you will prevent other developers from adding this file again.
If you're not a maintainer, then i don't think you should do anything, but address this issue to the maintainer.
II. I'm a strong believer that hidden files of any nature are most of the time not supposed to be put into the repository exactly for that reason. Therefore i think that you should do the same thing with .xcodeproj as with .DS_Store and put it into .gitignore and commit it. .gitignore is the exception for the rule above.
III. If those files are properly ignored , then there will be no issues in future with them. If they are already in the repo and somebody wants do such cleanup it should be done by maintainer and communicated inside the team.
Hope that helps!
git filter-branch might help you to remove unwanted files (.DS_Store files) from your repository -- see e.g. https://help.github.com/articles/remove-sensitive-data
If a clumsy git commit has added files you should be able to replay the corrected changesets onto a clean repository.
You're right in the sense that if a .DS_Store is already added the .gitignore won't be of much help however I think this is still a good resource for you and others.
When I start a project, I normally look at this list to see if there is a good .gitignore already existing. More specifically for you, this one is the Objective-C .gitignore.
Hopefully those resources are of some use.
As a Mac user you should download a tool like SourceTree which supports Git Flow. Git Flow will help you establish some best practices around how your collaborators will commit code to the repo and at the very least make merge conflicts less frequent and more manageable. For a set of gitignore files for various project types you can go to GitHub and download one that is ready to go. For Xcode they have it listed as Objective-C.gitignore. That is a good starting place and it even covers Cocoapods. If you're using external libraries, your project should use CocoaPods so that you can isolate that code and keep it outside of your repo and avoid git submodules.
Now when you find a file has made it into your repo like .DS_Store just remove it, and move on. Make sure you add it to the .gitignore file that is checked into the project.
As for xcodeproj... there shouldn't be that much customization within the file that is user specific since the above mentioned gitignore filters that out. If a scheme is to be shared make sure you check shared under Manage Schemes and you will check in files in that subdirectory. You should be using automatic selection of certificates so the only real choice is Developer or Distribution. You should also take advantage of variables provided within Xcode that avoid hardcoding complete paths. When trying to think of an example Plists came to mind, in this case, you might have written /Users/me/MyProject/Resources/MyProject.plist, but instead should use $(SRCROOT)/resources/MyProject.plist.
I deleted default.png from my resources folder because I wanted a different image for the loading screen, but I just deleted the reference which was apparently a dumb thing to do. I dragged the new image into resources and tried to change the name to Default.png, but it won't let me, which I think is because the first Default.png is still in the repository somewhere. Anyway, how do I delete that image(and others with which I have probably done the same thing) from the repository when it is no longer visible in xcode?
What kind of repository is it? Subversion? Git?
The SCM integration in Xcode is great for checking out files and committing changes without having to leave the IDE, but it's hardly a full-blown GUI front end to either svn or git. It may be possible to fix your mistake by adding the file back to the project and then deleting it in Xcode in such a way that Xcode will remove it from the repository for you, but the simple solution is to just delete the file from the repository yourself by using the appropriate version control command. For example, if you're using Subversion you could:
svn remove default.png
to remove the file from your version of the repository. When you commit your changes, the file will be deleted in that version. (It'll still exist in previous versions -- that's the whole point of SCM, after all.)
After that, you can create the new file and add it to both the project and the repository in the usual way.
You need to manually go into your app's file structure and delete the image files themselves. Also, it is usually a good idea to "clean" the app whenever you remove files or references to files from an XCode project, since XCode can be a bit temperamental about removing files; the key combination for this is
Hope this fixes your problem.
Clean all targets should work (at least it worked for me). You can try the following:
a) delete the reference from "Copy Bundle resources" of your target
b) delete the app from Simulator/Device
c) clean all targets
Caleb is absolutely right. That fixed the problem here as well for the most files.
An easier way to get an overview of the accidentally un-deleted files, is creating a bookmark of the working copy with Versions (SVN Software - in case you use SVN). There you can detect the problematic files grafically and delete them. I always have to do this after restructuring the project folder.