How do you send code review requests with git when devs do not have public work repositories?

Normally in Git, each developer will clone from the origin into a personal tracking repo, make some changes, then send a fetch request to the manager referencing his per开发者_如何学运维sonal machine which has a git-daemon, or web server, or allows the manager to connect to it with ssh.

For some changes its alright for the dev to check in stuff himself. For larger ones, other people like to look at it before it gets checked into master. So the dev does have the privilege to check into the repository.

But what if the manager couldn't connect to other devs work machines, and only had access to the origin git repo, or email? What is the best way to send the diffs to him for review?

We could send patches in an email or the dev could push his branch out to origin and tell the manager to git fetch origin; git diff master..case223. Or is there another better way?

---

I would use

git format-patch <branch-to-compare-against> --cover-letter -o patches/

which will essentially create the appropriate patches for your commits and then

git send-email --to <receiver@example.com> --annotate patches/*

Check the man pages:

• format-patch
• send-email and the example section

---

Git bundle

git bundle create myproposal.git origin/sharedbranch..HEAD

You can receive it as if it were a repo:

cd myworktree
git pull /tmp/myproposal.git

Incidentally, git bundle is also the most effective way to backup your entire repo, e.g.

git bundle create /tmp/backup.git --all --tags --remotes

---

Allow the devs to push to certain branches on the same repo. Use gitolite to administer who has what kind of access to what branch. No need to email stuff back and forth.

UPDATE: since then, I've written this article: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

Hope this helps.

---

Shameless advertisement: I suggest you also to consider Gerrit.

We use it for our code reviews, and it's an amazing tool (especially the possibilities for access rights). With that, every developer here can push his changes into the review branches (and only there), and the other developers can review the changes (they are also automatically built and tested by Jenkins and get verified if the tests were successful).

In your case you would have the right for the manager to submit a change into the repository, we enabled it also for the developers and made only a workflow restriction, that two developers have to review a change to submit it.

---

Note: in addition of git send-email, you can use the git contacts contrib script, to list potential contacts interested by your email.

With Git 2.14.x/2.15, that script also detects the "Reported-by" section.

See commit 09ac673 (21 Jul 2017) by Eric Blake (BlakeEric).
^{(Merged by Junio C Hamano -- gitster -- in commit 6d2b8a3, 11 Aug 2017)}

"git contacts" (in contrib/) now lists the address on the "Reported-by:" trailer to its output, in addition to those on S-o-b: and other trailers, to make it easier to notify (and thank) the original bug reporter.

git-contacts: also recognise "Reported-by:"

It's nice to cc someone that reported a bug, in order to let them know that a fix is being considered, and possibly even get their help in reviewing/testing the patch.

Of course...

• S-o-b: means Signed-off-by:
• trailers, formalized in 2014 are the other part of the commit (Signed-off-by|Reviewed-by|Acked-by|Cc)