An introduction to git-svn for Subversion/SVK users and deserters. This article is aimed at people who want to contribute to projects which are using Subversion as their code-wiki . It is particularly targeted at SVK users, who are already used to a work-flow that involves disconnected operation, though this is a tiny subset of the workflows supported by the git suite. Subversion users can skip SVK and move straight onto git-svn with this tutorial. People who are responsible for Subversion servers and are converting them to git in order to lay them down to die are advised to consider the one-off git-svnimport , which is useful for bespoke conversions where you don't necessarily want to leave SVN/CVS/etc breadcrumbs behind. I'll mention bespoke conversions at the end of the tutorial, and the sort of thing that you end up doing with them.
This is quite different from the Git - SVN Crash Course on the Git home page, which is intended for people who are familiar with Subversion who want to work with Git mastered projects using Git. Sam Vilain Contents: What!? Git-svn-tutorial – Parrot. Import Straight from the SVN repo ¶ First, we need to fetch a copy of the repository. git svn clone -s -r 40000:HEAD # choose some recent-ish commit -s is for --stdlayout which presumes the svn recommended layout for tags, trunk, and branches. -r is for the revision to start taking history from. If you want to include all of the history, just leave that option off, but it will take a very long time, and you really don't need all of it.
NOTE: The older a revision you choose, the longer it will take to import. But you will not be able to "git blame" past the earliest revision you import. This takes a clone of the repository at that revision; to update it to HEAD, you now need: git svn rebase Which is very similar to svn up . From the leto's github mirror ¶ Because importing all of history is *very* time consuming, DukeLeto has already gone through the trouble and maintains a github mirror of Parrot at . and finally .gitignore. Learn git one commit at a time. Ignoring files. Committed 19 Jan 2009 We don’t need Git to version everything in our projects, be it compiled source, files with passwords, or temporary files that editors love to create.
Usually keeping stuff out of your VCS’ hands is a task that is hard to manage and annoying to set up. Not with Git! Using the .gitignore file along with some other options, we’re going to learn how to set up per-project and per-user ignores. The easiest and simplest way is to create a .gitignore file in your project’s root directory. The files you choose to ignore here take affect for all directories in your project, unless if they include their own .gitignore file. This is nice since you have one place to configure ignores unlike SVN’s svn:ignore which must be set on every folder. Here’s a basic .gitignore: $ cat .gitignore # Can ignore specific files .DS_Store # Use wildcards as well *~ *.swp # Can also ignore all directories and files in a directory. tmp/**/* Of course, this could get a lot more complex. GIT: Using the stash. I bet the following has happened to you: you are happily working on a project and are in the middle of something.
You are not ready to commit your changes, because you your tests don’t pass yet. Then your client calls with a bug report that needs to be fixed right now. (You know how clients can be.) So, what do you do? Git features The Stash, which is as much as a good place to store uncommitted changes. When you restore your stash, you changes are reapplied and you continue working on your code. Stash your current changes $ git stash save <optional message for later reference> Saved "WIP on master: e71813e... " List current stashes Yes, you can have more than one!! $ git stash list stash@{0}: WIP on master: e71813e... Note the stash@{0} part?
Apply a stash $ git stash apply stash@{0} You may notice the stash is still there after you have applied it. . $ git stash drop stash@{0} Or, because the stash acts like a stack, you can pop off the last stash you saved: $ git stash pop $ git stash clear. Create a new Git Remote Repository from some local files (or local git repository) - Qugstart Blog. So you have some files or a new Rails application, and you want to add this to a new shared remote Git repository.
(I’m assuming you have access to your server and are setting up a remote repo over ssh.) I know I can never remember how to do it, so here’s a post for me and hopefully you! Create a local Git repository in your application for your local files. #On local machine cd foo_project git init git add * git commit -m "My initial commit message" Now, create the repository on your Git server. All of my git repositories are owned by a user git and located at /usr/local/git_root/. You can change these things accordingly to match your server setup. #On remote machine (Git remote repository)sudo su - gitcd /usr/local/git_root/ Create your new project git repo as a bare Git repository mkdir foo-project.gitcd foo-project.git/git --bare init Make sure permissions are set properly. ### UPDATED: If you are on git 1.7+ you can simply do this: git push -u origin master You’re done! There you have it. Git – setting up a remote repository and doing an initial ‘push’ « The Lucid. There is a great deal of documentation and many posts on Git out there, so this is more of a note to self as I keep forgetting the steps needed to set up a remote repository and doing an initial “push”.
So, firstly setup the remote repository: ssh git@example.com mkdir my_project.git cd my_project.git git init --bare git update-server-info exit On local machine: cd my_project git init git add * git commit -m "My initial commit message" git remote add origin git@example.com:my_project.git git push -u origin master Done! Team members can now clone and track the remote repository using the following: git clone git@example.com:my_project.git cd my_project Bonus To have your terminal prompt display what branch you are currently on in green, add the following to your ~/.bash_profile (I have my current directory displayed in cyan):