Every now and then I manage to screw up my local working copy of a project so badly that I just want to blow away my entire local copy, re-checkout from the shared repository, and get back to work. The only problem is that now that I'm using git, I tend to have several personal local-only branches that I don't necessarily need to share with the rest of the team. (That's pretty much the only benefit to centralized version control: All branches are backed up at the central repo. Then again... would I be using so many branches if I was still on SVN? No.) If I delete my entire working copy (including the .git folder), then I lose those branches.
Here's how I got around that problem the other day:
First, commit any uncommitted changes. If necessary, create new branches for them to live in. Then, push all of your local branches to the remote repository, one at a time:
$ git push origin local-branch-name
Then delete your entire project directory, and re-clone:
$ cd ..
$ rm -rf myproject
$ git clone you@yourdomain.com:your/project.git myproject
This gets you a fresh copy of the master branch of your project, but only the master branch. Now you need to get copies of your feature/bug-fix branches that you backed up on the remote server. If you list all of your branches with git branch, you'll probably only see master listed. However, there are references to each of the remote branches hiding in there. Do a git branch -a to see them all:
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/add-uri-to-entity
remotes/origin/api-versioning
remotes/origin/master
To make a local copy of one of the remote branches, check it out like this:
$ git checkout -b api-versioning origin/api-versioning
This is short hand to create a new branch named "api-versioning", base it on the branch named "api-versioning" from the "origin" remote, and check out the branch. Now you've got all of your local branches back, but they're still in the remote repository adding clutter that nobody else on the team needs or wants. Here's how you delete them from the remote repo:
$ git push origin :branch-name
Don't ask me why the syntax is this way. I have no idea. But it works! This only deletes the branch from the remote repository, leaving you with your local branch to work with as needed.
Posted in
Git
| No Responses Yet
March 22 2011
Almost a year ago I wrote about my initial thoughts on switching from Subclipse to Subversive, and it continues to be one of my most-googled posts -- not to mention that people encouraged me at the time to follow up later. I think it's about time.
Where are they now?
The first question is, of course, do I still use Subversive instead of Subclipse? The answer is yes... when I have to use Subversion at all.
To be honest, I've moved as much as is possible to Git -- even more than was true when I wrote my last entry. I mentioned at the time that I preferred using Git for my personal projects, for which I didn't have to worry about collaborators resisting the change, because there are no collaborators when working alone. But I spend more time working as part of a team (at work) than I do working on my personal projects, and 90.6976% of my work projects use Subversion. For a while I continued to use Subversive, and it got the job done, without the problems I experienced in Subclipse. Subversive is available through the official Eclipse Helios update site, which is probably an indicator of general consensus on the better option.
Then I started playing with git-svn, hoping I could make it work well for my needs. A few weeks later, a colleague on another team posted a blog entry about how he was using git-svn for his work projects. I guess that was what pushed me over the edge, because before his entry I was only using git-svn for 1 project, and after, I started using it everywhere possible.
Git-SVN
Git-SVN is a bridge baked into git -- not a separate tool you need to install -- that allows you to use Git as your SVN client. You can create a local copy (a git clone) of a subversion repository, use it just as you would any other git repository, and then push your changes back into the subversion repository when you're ready. The process is fast and painless enough to read from and write to your subversion repository all day long. In case it doesn't go without saying, this is tremendous.
There are lots of things to consider when working collaboratively using git-svn. The workflow choices are numerous and all outside the scope of this entry. But the important takeaway is that if you're a git-head, and I am, then most of the time you can use git-svn instead of Subversion.
When can't you use git-svn? The situation where I still find myself using Subversion, and thus Subversive, is when I'm working on a shared project on a remote development server and setting the project up to run locally would take longer than making the code changes. Not only would the setup be more onerous, but after pushing my changes back into the SVN repo, I would have to go run an svn up on the shared development server -- one more thing to forget to do. Other than those types of projects, I've been svn-free for several months now.
Take the plunge
Distributed version control is here to stay. DVCS isn't going to kill SVN, just as SVN didn't kill CVS, but if you want to work on distributed agile teams (for example, most modern open source projects), DVCS is the clear choice. It may be another flavour: Mercurial, Bazaar, etc; but the concepts should pretty easily transfer between them. In the long run, you'll be better off for having learned something new.
Posted in
Git |
Subversion
| 3 Responses
February 25 2011
When you create a new ColdFusion project in CFBuilder, you end up with 3 things in your project folder:
- A .project file -- this is par for the course in Eclipse
- A .settings folder
- And a settings.xml file
During the pre-release process I voiced my opinion that this was too much meta and that they should find a way to cut back or combine where possible. That hasn't happened. In addition, I complained that the file name "settings.xml" is too generic and quite likely to be something that the average developer would want to create for their project. This, too, seems to have fallen on deaf ears.
Oh well. Maybe next time.
However, in the meantime, I've created a quick shortcut for my Mac to create a new git repository and ignore all of the CFB Project Meta files all in one step. On Snow Leopard, edit the .profile file in your account folder (/Users/[your username]/.profile) and add this line:
alias cfgit="git init;echo '.project' >> .gitignore;echo '.settings' >> .gitignore;echo 'settings.xml' >> .gitignore;echo '.gitignore' >> .gitignore;git status"
It all has to be on one line to work properly, but I'll break down each command individually here so that it's easier to read.
alias cfgit="..."
Here we're creating a bash command alias. This translates to, "When I type cfgit I want you to do [this] instead." Where [this] is what you put inside the quotation marks. You can put multiple commands here as long as you separate them with a semicolon.
echo '.project' >> .gitignore;
echo '.settings' >> .gitignore;
echo 'settings.xml' >> .gitignore;
echo '.gitignore' >> .gitignore;
Each of these appends a new line to the file .gitignore with the contents of the single-quotation marks; so in this case it's adding a new line for .project, .settings, settings.xml, and .gitignore (ignore itself). By using >> instead of >, you append to the file if it exists, or create it otherwise. If you're unaware, the .gitignore file tells the local git client which files in the folder are to be excluded from the repository.
Lastly, it runs git status to show the current status of the folder/repository; mostly just as a sanity check to make sure that everything that I want to have happened has.
Posted in
Apple |
CFBuilder |
Git
| 4 Responses
July 06 2010
