views:

111

answers:

3

Hello everyone.
I'm having some troubles in understanding Git team-working principles.

Consider a team of two programmers: A and B. They are working on a Project. Also, there is a remote server with a repo on it. A and B are collaborating remotely. There are some code in the repo already.

I have a favour to ask you for help on organizing their step-by-step workflow on Git.
1. Have they to create their own local branches?
2. How they could upload working code on a production server? rsync?

Any help will be appreciated.

A: 

checkout this screencast: nettuts

its for beginner on git(also github).

there is a ton of git clients in the web, search google for that, because we dont know your OS.

choise
@choise Thanks for link, but I want to hear from your own experience how I can achieve efficient workflow. And, of course, It doesn't depend on OS peopel use.
Darmen
A: 
  1. Each developer will have their own clone of the repository. They can create branches for topic work as and when they want to. Their personal clone is their own turf, they can do whatever they want.

  2. Each developer should have their own remote public repository, which they can push/pull to/from. Typically, if you want to release code, there will be one person who finally decides what is going to go into the release and what gets cut out. That person's remote repository should have a branch which represents stable releases. Say A is the release manager who wants to incorporate B's work into the release. Then A will wait until B pushes his work to his own remote repo. Then A will pull B's work to his local clone, try things out, merge, commit, and push to his own (A's) public repo for release.

In (2) I've described only one of the many different workflows that are available for use with a distributed SCM like git. There are many others. This page from Pro-Git is especially nice in describing some others.

sykora
+1  A: 

It is not required for programmers to create their own branch to work. In the simplest case, programmers will commit to the "master" branch of their own repository, then git push those commits to the upstream repository.

To deploy to a production server, one way to do it is to use git clone on the production server to get a local repository. Then, to update the production server, log in and git pull. Any changes that have been committed to the main repository will be applied.

Developers can optionally create their own branches for either their own use (in their local repository only), or branches for sharing with others (by pushing the branches up to the shared repository).

Greg Hewgill
+1 but just getting my own feet wet with git I have to say that while everything you write holds true I think it will be overwhelming to the OP. If OP needs to ask if he should use rsync, it is obvious he is more on my plane than on yours.
Lieven