Coder collaboration best practices using Git [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 2 years ago.

Improve this question

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 c开发者_开发技巧ollaborating 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.

---

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).

---

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.