I'm developing an iPhone application with another developer. Our git repository is situated on the remote server.
So we are working with our working copies and then we do commit, pull, push one by one and we get our local working copies synchronized with server and with each other.
Everything worked fine until this day. Other developer successfully pushed his changes to the remote repository, and now it is my turn: commit, pull changes from the remote repository, maybe merge them somehow and then push my working copy to the server.
But when I'm trying to pull changes (using xcode's built-in git) I'm getting an error:
"The operation could not be performed because "%reponame%" has one or more tree conflicts".
Please, guide me through the process of solving this problem. And, please, provide useful tips to avoid this problem in future.
I guess xcode uses option to force fast-forward merges when pulling from repository. That is not bad idea, becouse it prevents you from undesired merges.
Try to use git pull --rebase (resp. check some appropriate checkbox in xcode), it should remove your changes, download new version and then apply your removed changes back. Conflict will occur at the last step so you will solve it and commit that changes again. Then you can push them on server.
Related
I am not able to upload project from Xcode to bitbucket. I have committed but it is not updating.
When you commit your changes in git they are only tracked on your local machine. This means that your local copy is versioned (and you could revert back to a previous version if needed)
If you want others to see your changes, you need to push those changes.
i.e. git push
This sends your commits to a common 'server' where others can retrieve them by performing a pull.
A really good set of tutorials for Git was put together by the folks at Atlassian: https://www.atlassian.com/git/tutorials/
In short, update your local copy before pushing your changes
git pull
Then push your changes:
git push
We are two developer and we want to work on a same project at the same time. So, we use GitHub. However, we couldn't do this.
This is our problem;
I am pushing new xcode project to our master, then, my friend are pulling this xcode project. Every thing is ok since here. Then, I am changing some codes, then, I am pushing (commit and push) it again. When my friend change some codes (he didn't pull) and push it, there is an error like this: "The local repository is out of date. Make sure all changes have been pulled from the remote repository and try again."
Actually, we want that, we change some come codes, then, I and my friend push it, then these two file will be merged. How can we do this?
he will need to do git pull --rebase which will pull the branch and put his changes on top of yours
you should really branch each feature though and work on the conflicts during merge
This might be verbose, but I'm just starting out with git, so I'm still learning here.
Before now, I've had a team of developers all working off of the same hard drive with a local copy of all of our dev files. So we have 1 hard disk and 4 developers. All of us use sublime text and work on the projects together. We all work in the same room, so it's never been an issue to work on the same project at the same time. We just don't work on the same file at the same time. Not the greatest system, but it worked at the time.
Now we want to introduce git to the team for all of the reasons a VCS is important. The problem we're running into is files being locked by one user and no one else can use git on that repository.
Here's an example. I log into my mac in the morning and make some changes to files in Project X located at /Volumes/dev/projectx/. I open terminal and commit those changes to the local repository (stored also at /Volumes/dev/projectx/). My coworker gets in and logs into his mac. He opens up his terminal to check the status on the repo he's working on. So he moves into /Volumes/dev/projectx/ and runs git status. He gets an error message that says the index is locked. In order to allow him to run any git commands on the repo, I have to completely log out (maybe just kill some processes, but I don't know which ones). After I log out, he can work as though there's no problem.
Is there any way that we can both work on the same local repository at the same time?
I've also discovered that, if I'm working in a project that has a git repository in it and anyone else even opens the project folder in a finder window, it completely locks me out from using that git repo (same index lock error).
We're willing to change the way we work on files, but since there are literally thousands of projects on the drive, it isn't really practical for each of us to have our own local copies of all of the files. Also, since many of the changes are a very simple text change of some kind, it seems tedious to host all of these repositories remotely and have to pull down all the files anytime we only want to update a single file.
I'm really looking for workflow suggestions here, but the question I asked is kind of the starting point here.
The whole point of using git is that you don't have to do this kind of crazy stuff.
I know what you've said about why you don't think you should all have complete copies. Here's the hard truth. You're wrong. Mostly. But that's ok, you said your willing to rethink how you work and that's good. Ill try to explain why its not that big a deal to have everyone use their own clones.
A assume all code is already in a remote repository - if its not, sign up on http://github.com or http://bitbucket.com and get a free repository, add it as a remote to your git repo, and push it up. Its really very simple.
Each of your developers should then make their own directory locally on their machines where they can clone the whole repository.
git clone http://github.com/yuoraccount/yourrepo ~/clones/localproject
The first time they clone, it will take a little time to download everything, but from then on, only each minor diff will need to be downloaded uploaded. Git is made to be efficient that way.
When you make a change, commit it, and push it up.
git commit -am "i made a small change"
git push origin master
Then everyone can pull it down.
git pull origin master
You can even all work on different branches, so your not just pushing to the same branch. This should all be really simple, and very easy to do.
You can also split your project into multiple repositories, but you don't really need to. Thousands of files is not a big deal, git can handle it without a problem. That's not to say that you won't have some challenges. Git is easy to use, but you'll eventually run into merge conflicts. They will be a little bit frustrating at first, but stack overflow has a thousand answers explaining how to deal with them - you should be fine.
This is what git is for.
Git is a decentralized version control system. The way you want to use git could be described as the opposite of decentralized.
There are a number of perfectly reasonable workflows possible with git, but all of them are going to involve each developer working in a local clone of some repo.
i guess that your "single harddisk" is really a single "network storage" that can be accessed concurrently. otherwise i don't see the problem (the harddisk can only be attached to a single computer at any time; whenever you unplug the disk, any locks should be released!)
anyhow, though you currently consider it impractical, you still might consider using per-user clones of the repositories.
the normal workflow of a multi-user repository would consist of a local clone of each repository on each developer machine (that is: a clone on your personal mac).
then the trouble with concurrently accessing the locked central repository doesn't exist!
it's exactly the use-case for which git was designed.
this would allow your users to work on the repository even without having access to your central network storage.
if you are concerned about disk-space, you might be happy to hear that git does a pretty decent job of compressing the data (just run git gc every once in a while in your repository).
if (for whatever reasons) you cannot have local copies (on the dev-machine) of the repositories, you might consider having per-user clones on the central storage.
git can use hardlinks for local clones, so disk-space should not be an issue here.
Section 4 of the Pro Git book (version 2) is about "Git on the Server" and gives some information about what the OP is trying to achieve.
The OP's situation calls for the "Local Protocol".
Here is how this works:
1. Create a local remote from your project
cd into your project and create the remote in your preferred location (in your example /Volumes/dev/projectx):
git remote add origin /Volumes/dev/projectx.git
2. Set the permissions for the remote
git init --bare --shared /Volumes/dev/projectx.git
This will set the permissions properly so that different users can push and pull to/from the remote. This command does not affect your Git history and is safe to run.
The --bare flag is used because all that is needed for a remote is a bare repository, that is, a repository without a working directory (a repository with only the .git directory and nothing else).
Note: this step is not described in the Git Book for the Local Remote protocol and is only suggested when setting up a Git server, but in the experience of a colleague, without using this step, the permissions were not set properly.
3. Push the data to your new remote
Assuming you have a branch called main (do this for any branch you want your collaborators to have access to):
git push --set-upstream origin main
4. Have your collaborators clone the remote
This works as with any remote:
git clone /Volumes/dev/projectx.git
From here on, everybody can push and pull to/from the local remote.
my Hg repo now needs to include a Git submodule (Restkit) as per the advised method in the site wiki.
However, I am not updating the git contents and should only be potentially reading/pulling in changes from the host.
It appears that when I came to make my first push of my main Hg repo it baulked at the Git one asking for a password. I think this may be because its attempting to authenticate against the Git site as well.
My questions are can I arrange this so that the Git repo is read-only(pull) or even static and/or get round the log in issue. Obviously the two different repos have different credentials.
Thanks.
P.S. using Atlassian SourceTree 1.5.3 on OS X 10.8.2, Xcode 4.5.1
I've just re-read this;
2.6. Synchronizing in subrepositories
Subrepos don't automatically track the latest changeset of their sources. Instead, they are updated to the changeset that corresponds with the changeset checked out in the top-level changeset. This is so developers always get a consistent set of compatible code and libraries when they update.
Thus, updating subrepos is a manual process. Simply run 'hg pull' and 'hg up' in the target subrepo, test in the top-level repo, then commit in the top-level repo to record the new combination. The onsub extension can be used to automate that.
Assume this means its not pulling the sub? but I still have the above issue of the password request.
You moved in the right direction, but not finished all required steps.
You have to have subrepository, create it by hand... and don't mix real subrepository with a) independent b) nested repository
When you'll convert nested to subrepo push into master repo will not perform push to subrepo (except it requested)
Switching to GitHub and can't seem to find information on how to do something I used to do with SVN:
First of al I'm a tester so I never commit changes, but I do need to keep a number of local copies of the project each with a small difference to trunk - staging, production, decreased timer values etc
I used to use CornerStone on Mac (just fwiw/don't have it any more), and a single update from SVN would update all my various local 'dependent projects' (all of them the same, apart from one or two lines, usually in a config file). I'd review the inevitable conflicts and almost always reject them, provided the only difference in the conflicting file was my customisation for test purposes, or if there was something new I'd merge it in and leave my staging environment URLs or whatever as they were.
Can I do this sort of thing efficiently with GitHub? (preferably using GitHub's/Xcode's or some other Mac GUI client?)
I did look at the documentation, but can't seem to find anything on this so any help much appreciated/maybe it's kind of unusual to be pulling changes to lots of almost-identical local projects and always be rejecting certain conflicts.. :)
Of course, the ideal solution is to not have configuration data tracked in the repository, or at least make it possible to override via some untracked file.
However, there's no problem with what you want to do in git. You just locally make multiple clones of your GitHub repository. In each, you can make your changes specific to that local copy, and then commit them. Then, when you want to update from the latest version of GitHub, make sure that you pull with:
git pull --rebase
... which will fetch the latest version from the server, and then try to reapply your commits with local changes on top of them. Unless the same parts of the files that you've committed changes to have also been modified in the new commits on GitHub, you shouldn't even have conflicts to resolve.
If you always pull like this, then the commit graph (history) of your project will always be the same as the remote, but with any of your local changes as the most recent commits on top of the remote history.
(I would hope that the GUI clients that you are using have an option to rebase on pulling new changes. Otherwise you can set this to happen automatically with the config option branch.<name>.rebase, where <name> is the name of your local branch.)