Posts Tagged ‘version control’

TechTip: Moving a Project Between Git Repositories

I tend to write these so that I do not forget them, and possibly to help others who may be face similar challenges. The question is why would somebody want to do this, well usually its because of a change in Git hosting providers or probably change in project ownership.

The process is as follows:

  1. Check the configuration of the remote repository
    local-box:change-url ssmusoke$ git remote -v
    origin https://github.com/ssmusoke/project-repo.git (fetch)
    origin https://github.com/ssmusoke/project-repo.git (push)
  2. Rename the url of the current remote repository from origin:
    local-box:change-url ssmusoke$ git remote rename origin oldrepo
    local-box:change-url ssmusoke$ git remote -v
    oldrepo https://github.com/ssmusoke/project-repo.git (fetch)
    oldrepo https://github.com/ssmusoke/project-repo.git (push)
  3. Create a new origin pointing to the new remote repository
    local-box:change-url ssmusoke$ git remote add origin https://github.com/ssmusoke/newproject-repo.git
    local-box:change-url ssmusoke$ git remote -v
    oldrepo https://github.com/ssmusoke/project-repo.git (fetch)
    oldrepo https://github.com/ssmusoke/project-repo.git (push)
    origin https://github.com/ssmusoke/newproject-repo.git (fetch)
    origin https://github.com/ssmusoke/newproject-repo.git (push)
  4. Sync the project to the new remote repository (if any issues occur the old url is still available)
  5. Delete the old url (only after confirming that everything works fine with the new url)
    git remote rm oldrepo
Advertisements

Software Development Process – The Journey

I am starting a new set of topics on my experiences in the practical application of the software development lifecyle (SDLC). The tools are as important as the people, however a versatile process will always allow you to change one without the other.

My initial exposure to the SDLC was through the Rational Unified Process (RUP – http://bit.ly/mJq8Fu) in 2001 which along with the Unified Modelling Language (UML – http://www.uml.org/) during my days of Java development. Over the next 5 years there were a number of other influences:

  1. Eclipse (http://www.eclipse.org) vs JDeveloper
  2. Hibernate (http://www.hibernate.org/) Object Relational Mapping project, to ease the SQL needed to save and update POJOS (plain old java objects)
  3. Spring Framework (http://www.springsource.org) the first step towards a useable Java Framework from Rod Johnson, with Dependency Injection, XML bean configuration, Application Contexts all dealing with POJOS. I basically memorized his whole book J2EE Design and Development
  4. Martin Fowler, Refactoring – Changing the Design of Existing Code without affecting functionality
  5. Scott Ambler – Object-Relational Mismatch, Coding Standards, and Database Refactoring
  6. Kent Beck – Junit
  7. Design Patterns from the Gang of Four – while these were not immediately applicable, they were extensively referred to in refactoring and the spring framework
  8. Alistair Cockburn – Use cases – did not make so much sense till about 2 years ago
  9. Javaworld and the Serverside.com (http://www.theserverside.com) – excellently written articles on solving common problems and experiences before Google and StackOverflow (http://stackoverflow.com)
  10. Not forgetting the good old version control, have been using CVSNT (http://www.march-hare.com/cvspro/), yes CVS on Windows, however the product has been retired, so its almost time to move, though to what – Subversion, Mercurial, Bazaar???

Also mid-way was a change of programming languages from Java to PHP mainly due to ease of deployment for web applications.

Therefore the journey will touch on the different influences to a practical process that is still evolving.

%d bloggers like this: