I'm using (for the first time) Git as a source control of my iOS project. We are two persons working on this project. Everything was ok until the day that we modified the same file (different methods and lines).
So when I want to commit my modification xcode tell me to pull first, because my co-worker already committed his work. when I pulled I lost my local modifications.
To face this problem, what are the steps to make ?
Thanks
You'd be better off using a feature branch workflow. http://git-scm.com/book/en/Git-Branching-Branching-Workflows
This will allow you and your colleague to work on the same files with fairly little fuss. Share branches at your own risk!
Related
I'm programming in xcode (actually Phone Gap in conjunction with xcode) with git. I'm having a strange issue. When I create two identical branches and try to check out back and fourth between them with out making any changes git is telling me that I need to commit because a change has been made (this same thing is also resulting in merge conflicts). It says the changed file is:
platforms/ios/Butterfli.xcodeproj/project.xcworkspace/xcuserdata/benpearce.xcuserdatad/UserInterfaceState.xcuserstate
Can anyone explain what's going on and how to deal with it.
Yes, .xcworkspaces are simply files that Xcode uses to describe the workspace or projects.
IMHO, There's no need to check these files in at all, unless you share settings with other folks in your projects (and in your case, I suppose other machines that have a user named "benpearce").
In fact, you can safely add them to your .gitignore file.
More info can be seen here
Actually I have faced this issue many time during working with SVN. Most of the time I am working with VSS for source control but since last couple of months working with SVN.
We are using tortoise and AnkhSVN with VS 2010.
In our team there are 5-6 people and some of them are working on same file at a time. Now when somebody commit , we have seen that some other developer changes get vanished and Sometime we get some line with version number. This thing get consume lots of time and we have to resolve conflict and all.
Please provide information so we can avoid such issues.
If two developers are working on the same file and make changes to the same are of code, then you have to manually resolve this conflict. There is no way to avoid it, no matter which version control you use.
The version control cannot know what the correct code is, so it requires a human intervention.
There is no way around this, other than preventing the users from working on the same code. this is done in svn by locking the file.
Each developer must svn update before svn commit. Between the update and commit, the developer must do a full, clean build and run all tests to make sure their code still works after merging in all other developer's changes into their copy.
You can set svn:needs-lock on files or folders that need to be locked before making changes, they'll be forced to check for locks. When you will try to edit a file, you will be required to lock it first. And when it is already locked by someone else, they you get an error message, preventing you from making any changes. This can be done in Tortoise SVN in Properties -> Advanced
What is the best practice / process for sharing code using git between developers working on an iPhone application.
Everytime I follow the normal git-fetch, git-rebase origin/master, method from the command line I get conflicts in the .xcodeproj, .xib, and Storyboard files.
The .xib isn't so bad because its ussually easy to fix, however the .xcodeproj consistently corrupts and I haven't found an easy way to consistently fix it.
What's the best workflow to share project files and resolve conflicts with git?
Conflicts in project files are always a pain. The same thing happens in .NET development and Visual Studio. The best way to handle this is to not have too many changes to merge at once. You do this by merging in each other's changes on an integration branch. To keep branches clean, you don't merge that branch or the other person's back to yours. You rely on rerere to remember all your conflicts along the way. This is the workflow I use:
http://dymitruk.com/blog/2012/02/05/branch-per-feature/
If you really get stuck, you would likely look at what changes were done on the other side (what you're merging in), checkout your version of the project file, manually do what the other branch did to the project file, and then use that as the solution to the conflict.
The issue is that the IDE is doing it's own thing when you update your project. So sometimes, you need to manually use the IDE to simulate adding all the stuff yourself and using that file as the conflict resolution.
This is the dark side of using heavy IDEs for development.
I will start by saying this is probably a dumb question so apologies if I am staring at the answer but cannot see.
I have used VCS in the past primarily as a method of allowing me to revert my code if something goes wrong. I have always had a single lime of development. However I get into the usual trouble when releasing and starting the next version - dealing with bugs. So this time I decided to use branching (forking or whatever is the best name). I am a lone developer so I am the only one working with the repositiory. My scenerio is simple. I want to create a branch when I release so that I have a line for the released code and a line for the beta. I can then work happily on the beta. Now a bug comes in and I need to get back to the last commit for the release.
My question is what is the best way to get back that code in the IDE to work on it.
I have read that in Mercurial a simple way is to clone the repository including the working directory. This would give me two copies of the code base and I guess I can choose which one to load into the IDE. I would then use Push or pull to get the bug fixes from the release copy into the beta copy (I think).
I assume there must be another way however without cloning. How would I do that? I can guess at reverting to the last commit of the release code. Then I assume that loading the solution into the IDE would give me that. I am not sure where I would go from there when the code is done.
For the record I looked at a number of different VCS - I have used SVN in the past but wanted to go to a DVCS. I looked at Git, Bazaar, Mercurial and Veracity (and used Code-Coop in the past). You may think another tool would suit my needs better. Having tried the others however I found I could understand the way Mercurial works and the GUI tools such as TortoiseHg with the WorkBench and HgSccPackage (http://visualstudiogallery.msdn.microsoft.com/9bc074fa-9e1f-4ce2-a75d-b90e65f7475a) appeal
There are a lot of good documents and links here Introduction to Mercurial and I have read about different ways to branch that include using bookmarks and so on but they seem primarily targeted at multi member teams - which make sense of course
Many thanks in advance
You are mixing concepts a little, i guess you have SVN background ?
Just to answer you question, to 'get back the code in IDE' you will need to 'update' to a previous version. But this is considering you already have cloned the repository. Is your question about how to clone.. ? As you ask, there is no other way without cloning first. Cloning is the first step towards having a HG repository local. After clone, you can commit and push changes or pull and update.
To expand the answer even further and given that you are going to use Mercurial, here is what you should do:
read this : http://hginit.com/ - great HG (tutorial) by Joel Spolsky him self ! An introduction into HG and the concepts. You will need to understand this very good, since right now you are doing a lot of guessing, assuming and thinking :) HG/Git is different from SVN and in the begging the concepts might be hard to understand and to get used to.
for your project and regarding your question, have a branch called 'dev' or 'trunk' or 'version X' etc where you will commit all new changes.
have a branch called 'live' etc that will represent the current 'live' version. This way, whenever you need to revert back in time to the live version and to do a quick fix on it, you will 'update' to the tip of that 'live' branch, discarding all local changes (after you have committed to trunk! of course).
when putting a version to live, you will need to (assuming all changes are committed !) : update to the live branch then MERGE the version X into local (local being live ). This will include your versionX branch into live - it's what you need at this point. Then, either update back to version X branch or create a new branch - version X+1. This will take care of the versions and keeping the branches separate.
since you are using VS - install http://visualhg.codeplex.com/. HG source control integrated into VS.
I assume there must be another way however without cloning
Yes. You can use (named) branches inside single repo (I prefer HgSccPackage in VS), update to revisionbranch head, change, commit, merge
BTW, branching with bookmarks/clones/branches work the same (good) way for any size of team - it's a matter of taste
I'm doing a single developer Visual Studio solution and reached a point where I'd like to incorporate Versioning Control. Several posts address this issue, but one problem I'm facing is a large merge. I have a production copy of the solution and a beta copy. They are NOT dramatically different, but they will require a number of interactions I suspect. I'm using TortoiseSVN and have imported the production version.
Yes, I know I should have used Version Control from the start, but that is hind sight. Would it be best practice to simply use the beta as a reference and work the interations from scratch. Or should I branch off and import the beta separately, then attempt to merge the change. Or is there another alternative I'm missing.
Thanks,
dgp
well, I have experienced SVN in the past ... and I must say, it's lovely cause it's really easy to understand the concept, but it's awful terrible when things pass from the plain commit.
I'm currently using GIT (to host small code on GitHub) and Mercurial (Hg) (I use Kiln in the company - was recommended by myself so they can start using - and in BitBucket for personal use)
I have used SVN for more than a hole year and every time I need something from "the past" or to merge something, it was a nightmare, but the server/client concept was really a break deal and extremely easy to get it... but I found my self, over and over to do merging by hand :(
When GIT started to be hot, I was afraid to move as, dang! SVN was a pain, why should be different in a DVCS?
This videos rocked my world, [ part 1 part 2 ], only then I understood DVCS vs VCS and it was with this that I moved COMPLETELY to DVCS and never go back... proudly!
For your problem, I would install git (or hg), and then create a repository on the folder you have your current source with:
git init will tell your folder, "Hey, I'm a GIT Repo"
git add . let's add all files and folders to be tracked by git
git commit -m "initial commit" let's save all the hard work :)
So, now you have a tracked code, you can simple create a branch and overwrite all your files. YES, worry not, you don't need to have copies of your code in a folder called branch ;) no more copies! all is in the GIT database
then, after creating the branch, changed the files, added all files to be tracked on that branch and committed, safely do a merge :)
ohh, and you don't need a server connection to do all this, all you need is a computer with GIT installed... no more connection dependencies! DVCS is cool or what?! :D