Using git as a better SVN

We were an SVN shop - now we use git (cos all the cool kids are doing it).

Each dev checks in code locally on their own git tree while working on new features. When some work is ready to submit to the main repository we have a directory on a shared drive for each project. We then do a git push to that repo, and either a git sync or git pull to update an individual dev machine from the 'one true source'.

We had one accident when someone did a push to the repository and somehow managed to replace the main repo with t开发者_Python百科he dev machine's version of it's own git tree.

Is this the best 'git' way of doing things?

We are on two sites but the shared directory is common. A small number of devs who can generally avoid major clashes on the code area. All on Windows, using TortoiseGit, security is not too important but we have no admin support so a complex server solution is out.

---

Git is powerful. It is distributed, but doesn't restrict you from being a centralized, if you want to.

Unlike in svn tho', it is very essential to setup your own conventions and ways of doing stuff.

A very good model to follow would be illustrated in the diagram below

from the popular git branching model.

---

Take a look at the workflows at the following link with my preference being the integration manager workflow (similar to @simon's second option) and correlative to github's model: http://progit.org/book/ch5-1.html

---

Two common ways of using git are:

• All devs pull from and push to central repo (as you are doing now)

• Every dev have one private repo and one public repo. He pulls what he wants from the other public repos and pushes only to his own public repo.

If you choose the second option and your code doesn't have to be private, you could use github to simplify your life.

---

In our project, we have a central server with a gitosis-managed repository, with several branches. From there, each developer pulls the latest changes on the branch to be worked on, makes his own changes, commits locally and when it is compilable and tested (if possible) pulls again (merges any changes) and pushes.

Usually little features without much disruption are worked on directly in the main branch, while bigger changes are first done on their own branch (which may be shared by multiple developers this way).

Don't forget to delete your branches after finishing using them, else it gets confusing. I actually have a special branch named branches, which tracks with git merge -s ours ... references to all the other branches at their deciding points (branch, merge, end), so even if I'm deleting a branch without really merging (e.g. since I decided not to go this route, or it was only some bug-finding branch), I still have a reference to it and can revive it if necessary.