What is the most simple way to backup my project? Can I just copy XCode project (with hidden .git) directory to USB stick and copy it back when needed?
It will work fine, but it is rather inefficient. I've done it with timecapsule and this just works.
You can also create a "bare" repository on the stick and regular push your work to it.
This is a lot smaller than the original, but you will not have all your branches (unless you all push them of course).
If you have a second computer then you can push/fetch the project back and forth, and you always have 2 copies. If you fetch from the remote PC you get all the branches.
Sites like github and gitorious allow you to push your repository to the cloud and also serve very effectively as a backup.
This is what is great about distributed version control : so much flexibility.
If your project is tracked with git. You can backup the git repo with git-copy.
git copy /path/to/project /Volumes/usb/project.backup
Then you can restore your project with git clone
git clone /Volumes/usb/project.backup project
Related
I've got a repository. When downloading this repo, instead of cloning it, it seems that I accidentally simply downloaded the source instead. Now I've come to commit my changes and noticed that the folder I'm working in is, in fact, not a repository at all but just some random folder.
I've found various ways of initializing a new repo from existing contents. But how can I initialize an existing repo from my existing contents? I added the remote repo as a remote in the GitHub for Windows client, but it doesn't seem to have had the desired effect.
Just to be clear, the intended outcome is as if I had cloned it properly in the first place- history, diffs of the changes I've made from the latest in the repo, the works.
I've tried some solutions involving git clone, like "Clone into a new folder and then just copy and paste the .git folder". However, this seems to have the effect that Git thinks that I deleted and re-added every line of every file in the repository instead of the changes I really made.
From what we talked about in the comments, you should copy over the actual data to the properly cloned repository as opposed to the .git folder. This way, Git has a chance to pick up the changes without introducing any aberrant or unusual state issues.
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.
I have a project created for me by teacher and I have to improve it. He created a repo on Git Hub with branch for me. I'm trying to pull the project files from that branch directly to Xcode and Xcode refers to the branches that I have created which are empty, not the master one. Can't find any adequate manual for that as well... Please help...
so github uses git to manage repositories, so this question has more to do with git than with github.
Git is a distributed-repository source-control system, which means that every machine has a full copy of the repository, with all of its history and branches. This means that your local repository that you cloned from GitHub has all of the branches on it.
So, your problem is actually just that you need to switch branches locally to the branch your professor created.
In a terminal you can execute
git checkout <the-name-of-the-branch-your-teacher-created>
and that should do it. :)
Xcode is simply looking at the files in your working directory, so switching branches will update the files in Xcode as well.
For more git information check out the git book or any of the other countless git resources online!
Well using Git is fairly simple and as specified above can pull the project (either complete of specific brach and then import it.
OR
While running Xcode you can follow below steps -
Click on Check out an existing project.
Enter Repo link as shown below and hit Next.
Select the branch that you want to pull and hit Next.
Note As shown in Image Xcode version 8.2.1 is used.
I was using "Tortoisesvn" to take control of my programs's source code. But sometimes, I had problems/bugs while using it. So I decided to use "git"( http://code.google.com/p/msysgit/ ) Also, I'm using git with "Git Source Control Provider" visual studio plugin. Source control is very easy with this extension.
So now I have few noob questions...
1) Where is the main repository? Where is the folder that my project's files backup?
2) Is this program working completely offline? I mean how secure is that? Are there any changes that someone can steal your files( repository/source codes etc. ) ?
Thanks for any input*
Best Regards,
Git is different from SVN in that Git is a DVCS - Distributed Version Control System. That means every "working copy" is a full blown repo. Repos can talk to themselves and there is no need for a main repository ( but usually there is a main or "blessed" repo that is the central.)
So when you created a Git "working copy", you created a repo. You setup another repo on different maching / server and push to it if needed.
I don't know what you mean by "backup", but the metadate for git will be under the .git folder ( it will be hidden unless you have selected to show hidden files and folders in Explorer)
Another feature of DVCS that results from having full blown repos and no main repos is that it works offline. You get full history and you can commit without contacting any server etc. Again, I don't understand why you would ask about security in this context? If it is offline, wouldn't that be the most secure? And Git has lots of security and integrity mechanisms.
Git doesn't work with a centralized "main" repository. Each repo is considered an equal to every other repo.
Git can work completely offline (unlike some other source control systems), but in order to push changes to other repositories you'll of course need to be connected in some way to the machine where the remote repo is hosted.
After following several tutorials I was finally able to take my existing, non-Git-Repository XCode Project and get it uploaded to a repository on BitBucket. I'm completely new to git but I'd like to start working with versioning. Since I'm a complete newb I'd rather not be working with the command line all day (which is what I had to do to get the project on BitBucket).
XCode's organizer now has access to the BitBucket repository. I successfully cloned the project back to my hard drive. My question is this: From now on, will the projects be in sync with each other? I'm not familiar with the lingo, and the difference between a branch and a fork. Essentially, I uploaded a 1.0 codebase and I want to start working on 1.1. I'd like to either fork the code or branch it so that the original project remains for reference. From what it appears, when I clone to my hard disk, XCode creates a new local repository instead of saving it on BitBucket.
I'm confused, please help!
Forking is a server-side operation where you clone the repo. For BitBucket, it is generally used with Mercurial (see "Forking a Bitbucket Repository").
This isn't what you have done.
You have simply cloned your BitBucket Git repo (now that BitBucket also support Git, and not just SVN and Mercurial) into a local repo and imported it in your XCode editor.
You can check it through command-line (git remote) or in XCode (See "Version Control System with XCode 4 and Git").
Note that you need to use an https address for your BitBucket clone address for being able to push back to the BitBucket repo from your XCode-managed local repo: see "Bitbucket + XCode 4.2 + Git".
For more on the basis of Git (especially branches), you can follow first the small labs from gitimmersion.com.
What you want to do is Branch your code from your 'master' i.e. your 1.0, to a 'develop' branch i.e. your 1.1 version. This is the simplest way for you to start getting used to version control. Once you create the branch using Xcode, the project in Xcode you are working on locally will be on that branch.
As you make changes to the code on that branch, 'commit' them from Xcode, and then 'Push' them up to Bitbucket (all done from the same menu in Xcode File>Source Control>...Xcode will ask during a push which branch to send changes to so make sure you select your Develop branch.
This will keep your local copy and your remote repo in sync as you develop your code.
This chapter in the Xcode user guide helped me immensely:
https://developer.apple.com/library/mac/#documentation/ToolsLanguages/Conceptual/Xcode4UserGuide/SCM/SCM.html
How often you should do the commit and push dance will come from experience.
Good Luck.