after a lot of hesitation I finally decided to move my VCS from dear old Subversion to GIT, and so the repository of my projects. I still am a “noob” about GIT, but my latest experience with SVN in a team (the “merge” nightmare: sounds familiar?) definitely persuaded me.
I won’t dive in the GIT philosophy and functionality (here’s a really well written and free book: Pro Git by Scott Chacon). The only thing I would underline, though, is that GIT is conceptually really different from Subversion; so, you have to get used to that and to keep in mind that in this two VCS the same terms and operations (may) mean and works in different way.
Now, back to topic, after reading some basics, I thought I was ready for the big jump, so my very first step was to move my repositories from SVN to GIT. I have my own server with both Subversion and GIT servers, so as prerequisite you should set up your own Central repository (well, of course you may also use GitHub).
The “committer” (ie, the developer that commit its work on the central repository) should have an ssh access to the server that hosts the repository.
Then, inside Eclipse, the EGit plugin is required.
Here’s a quick step-by-step guide
2) Share project with GIT (Team -> Share Project…); click “Create” button to create a new repository (for example /(USER_HOME)/git/(PROJECT_NAME)) – keep in mind that the working directory (i.e. where the sources are stored) will be moved INSIDE this one, so you will have a Target location like /(USER_HOME)/git/(PROJECT_NAME)/(PROJECT_NAME) – your original “working directory” (for example, the one inside the Eclipse workspace) will be deleted; be sure to UNCHECK “create repository inside parent folder”
3) All the files will be shown with a question mark because they are all untracked; moreover, beside the name of the project “NO-HEAD” will be shown
4) Switching to “Git Repositories” view, the newly created repository will appear; take note that for the moment being “Branches” folders (“Local” and “Remote Tracking”) and “Remotes” are empty
5) on SERVER, create a new bare repository; for convention bare repositories names end with “.git”, so a good name could be (PROJECT_NAME).git
- git init –bare (REPO_NAME)
6) check permissions: repository’ directory should be owned by the server’s “git” user, and belong to a group of which the “committer” user is part; moreover, the repository must be “shared” (the following commands are related to Linux machines)
- sudo chmod -R g+ws (REPO_NAME)
- sudo chown -R (git_user):(git_group) (REPO_NAME)
- cd (REPO_NAME)
- git config core.sharedRepository true
7) Done with the server and back to Eclipse; now we have to link our local repository to the Central one just created, and to allow secure access, we will use the “ssh” protocol; from “Git Repositories” view right click on your repository “Remotes” and select “CreateRemote..:”; let’s keep default settings (“Remote name”: origin and “Configure push” checked)
9) In the next screen, insert the URI of the Central repository in the following format ssh://(username)@(server_address)(:port)/FULL_PATH_TO_REPO_NAME (the one created at point 6) and then click “Finish”
10) Now that we are back to the previous screen with the correct URI, click “Save” and close it
11) Back to “Package Explorer” view, Right click on the project (it should still have the question marks, meaning it has something to commit”) and select “Team -> Commit”
12) From here, click on “Commit and Push”: an authentication window will eventually appear if you did not save your password at point 9 or if your ssh is configured with preshared keys; after successful “login” a “Results” window will show
After all, it is not *that* hard. There a lot of details I have not covered. The book I have pointed to in the preface (Pro Git) it is all about command line, so maybe it would be a good starting point to first learn at least the basic of GIT using the command line; then the operations we have done would be much clearer.
I have found a lot of forum and posts of people getting litterally crazy with GIT, or EGit, to the point to leave it be. I can not criticize them because it is what happened (and still happen) to me too. In my humble opinion, GIT require a significant change in the way we deal with VCS, but I think it is worth the effort (hey, after all Linus Torvalds made it, and the Linux kernel is managed by it: there must be a good reason!).
Finally, here’s the link to full guide to Egit.
I hope you enjoyed the tutorial. See you soon!