tags:

views:

491

answers:

2

I'm using msysgit for my embedded project. Local repositories are great, but I also like to have repositories on our network disk:

  • it provides daily backup
  • my changes are visible for everyone

I have been trying to get the best of both worlds by doing the following:

  • working on a repo on my local disk (faster building, always latest uncommited files with me)
  • committing very often (always nice with fine granularity)
  • cloned the local repository to the network disk
  • doing a fetch from the network repository every now and then (at every startup with help of a batch file, every few commits when I don't restart).

I'd be very interested in knowing how other users set up their msysgit repos, how they publish, how they backup, on so on.

And of course, I'd appreciate someone telling me I'm doing it the wrong way :)

+1  A: 

We have been using github for a while on an online ruby on rails project.

We clone, change, commit to our local repos and once sure we push.

Konstantinos
I see. In my case, I want an exact copy of my local repo on the server (including all my commits), while still working locally.github is not an option, our source code is of course confidential.I suppose I could do a push to my clone on the server, instead of fetch. But I never navigate in the server copy, so I don't care about its local branches.
Gauthier
Well, GitHub doesn't prevent you from also having everything locally. You just have to remember to push your changes when you are sure about them. The only problem that agree you will have is the public access of your repository if you are on the free account. There are different plans in GitHub (not free) that allow you having private repostiries.
Petros
A: 

We use GitHub for hosted source code control. It's actually very secure for private repositories (using their paid plans) -- it uses SSH and keys to validate so everything is transmitted in a secure manner.

We treat our repos on GitHub as the "origin" copy for all of our repositories, commit all changes there, and then run "git pull" on our local dev machines to get the latest copy of the code.

We're still perfecting our deployment strategy using git, but the current plan is to have a tag named "stable" which we'll pull to our staging and production servers when appropriate.

For backups, aside from cloning the repository in various locations, you should look into git-bundle. See a related question here.

calvinf