Guidance on using a remote Git repository for teamwork

I project I have been working on has now been split between me and another developer. I have created a Git respository at my client's host of choice, CodeBase, and both me and the other developer have been able to clone the rep开发者_C百科o back to our machines. He is not able to push back to the remote though.

I would like some guidence e.g. advice, links, etc. on how I must manage the SCC for this project. Should we all (total 3 team members) be able to, or allowed to, just clone the repo, make changes and local commits, then push to the remote? Then, I would also like to know how to branch or tag on the remote repo before test releases, so we have a trunk we are all working on, and a branch (and previous branches) of the code as deployed. Our main reason for this is if we break the trunk, we want to roll back to the 'last good branch'.

I also need to learn a lot more about rolling back commits and changes to individual files. The Man Pages on my installation aren't working, and aren't very friendly. Some tutorial or book recommendations would be nice.

We're all using msysgit on Windows 7, and as I mentioned, the remote host is CodeBase.

---

Here is a good link describing the different possible workflows using git GitWorkflows

Next is the a great cheat sheet with a quick reference for a lot of the commands you are describing Cheat Sheet

Finally here is a good intro resource for beginners. It is indexed on topic rather than just presenting a list of commands: Intro

Hope this helps,

---

It sound like you need basic instruction on using Git. Pick up the book Pro Git, or read it online.

---

He is not able to push back to the remote though.

Make sure the user has correct access to the repo. If you are cloning over SSH then check the access permissions on the server file system.

Should we all (total 3 team members) be able to, or allowed to, just clone the repo, make changes and local commits, then push to the remote?

With git everyone can clone and make local changes. For 3 devs, I would say allowing push to remote is fine as well. Unless you feel there is a large experience gap between 1 and the other two.

Then, I would also like to know how to branch or tag on the remote repo before test releases, so we have a trunk we are all working on, and a branch (and previous branches) of the code as deployed.

Branching and tagging is simple:

# one time branch setup
git checkout -b BRANCH       # create/checkout a new branch
git push BRANCH              # share branch, and track it
git branch --set-upstream BRANCH origin/BRANCH
# getting the new branch (everyone else) 
git fetch                    # fetch/track shared branch
git -t origin/BRANCH         # (continued)

git tag -a TAG_NAME          # create a new tag
git push TAG_NAME            # share tag
git push --tags              # share all tags

I also need to learn a lot more about rolling back commits and changes to individual files.

You can undo the last commit with git reset --hard HEAD^. After you've pushed a commit to the shared repository, the best way to go back is using git revert. This command will create a new commit that undos whatever changes were caused by the specified commit(s)