-
1. 開始
-
2. Git 基礎
- 2.1 取得一個 Git 倉儲
- 2.2 紀錄變更到版本庫中
- 2.3 檢視提交的歷史記錄
- 2.4 復原
- 2.5 與遠端協同工作
- 2.6 標籤
- 2.7 Git Aliases
- 2.8 總結
-
3. 使用 Git 分支
-
4. 伺服器上的 Git
- 4.1 通訊協定
- 4.2 在伺服器上佈署 Git
- 4.3 產生你的 SSH 公鑰
- 4.4 設定伺服器
- 4.5 Git 常駐程式
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 第3方 Git 託管方案
- 4.10 總結
-
5. 分散式的 Git
-
6. GitHub
- 6.1 建立帳戶及設定
- 6.2 參與一個專案
- 6.3 維護專案
- 6.4 Managing an organization
- 6.5 Scripting GitHub
- 6.6 總結
-
7. Git 工具
- 7.1 Revision Selection
- 7.2 Interactive Staging
- 7.3 Stashing and Cleaning
- 7.4 Signing Your Work
- 7.5 Searching
- 7.6 Rewriting History
- 7.7 Reset Demystified
- 7.8 Advanced Merging
- 7.9 Rerere
- 7.10 Debugging with Git
- 7.11 Submodules
- 7.12 Bundling
- 7.13 Replace
- 7.14 Credential Storage
- 7.15 總結
-
8. Customizing Git
- 8.1 Git Configuration
- 8.2 Git Attributes
- 8.3 Git Hooks
- 8.4 An Example Git-Enforced Policy
- 8.5 Summary
-
9. Git and Other Systems
- 9.1 Git as a Client
- 9.2 Migrating to Git
- 9.3 Summary
-
10. Git Internals
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 The Refspec
- 10.6 Transfer Protocols
- 10.7 Maintenance and Data Recovery
- 10.8 Environment Variables
- 10.9 Summary
-
A1. 附錄 A: Git in Other Environments
- A1.1 Graphical Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git in Powershell
- A1.7 Summary
-
A2. 附錄 B: Embedding Git in your Applications
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. 附錄 C: Git Commands
- A3.1 Setup and Config
- A3.2 Getting and Creating Projects
- A3.3 Basic Snapshotting
- A3.4 Branching and Merging
- A3.5 Sharing and Updating Projects
- A3.6 Inspection and Comparison
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Plumbing Commands
4.6 伺服器上的 Git - Smart HTTP
Smart HTTP
We now have authenticated access though SSH and unauthenticated access through git://
, but there is also a protocol that can do both at the same time.
Setting up Smart HTTP is basically just enabling a CGI script that is provided with Git called git-http-backend
on the server.
This CGI will read the path and headers sent by a git fetch
or git push
to an HTTP URL and determine if the client can communicate over HTTP (which is true for any client since version 1.6.6).
If the CGI sees that the client is smart, it will communicate smartly with it, otherwise it will fall back to the dumb behavior (so it is backward compatible for reads with older clients).
Let’s walk through a very basic setup. We’ll set this up with Apache as the CGI server. If you don’t have Apache setup, you can do so on a Linux box with something like this:
$ sudo apt-get install apache2 apache2-utils
$ a2enmod cgi alias env rewrite
This also enables the mod_cgi
, mod_alias
, mod_env
, and mod_rewrite
modules, which are all needed for this to work properly.
You’ll also need to set the Unix user group of the /opt/git
directories to www-data
so your web server can read- and write-access the repositories, because the Apache instance running the CGI script will (by default) be running as that user:
$ chgrp -R www-data /opt/git
Next we need to add some things to the Apache configuration to run the git-http-backend
as the handler for anything coming into the /git
path of your web server.
SetEnv GIT_PROJECT_ROOT /opt/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/lib/git-core/git-http-backend/
If you leave out GIT_HTTP_EXPORT_ALL
environment variable, then Git will only serve to unauthenticated clients the repositories with the git-daemon-export-ok
file in them, just like the Git daemon did.
Finally you’ll want to tell Apache to allow requests to git-http-backend
and make writes be authenticated somehow, possibly with an Auth block like this:
RewriteEngine On
RewriteCond %{QUERY_STRING} service=git-receive-pack [OR]
RewriteCond %{REQUEST_URI} /git-receive-pack$
RewriteRule ^/git/ - [E=AUTHREQUIRED]
<Files "git-http-backend">
AuthType Basic
AuthName "Git Access"
AuthUserFile /opt/git/.htpasswd
Require valid-user
Order deny,allow
Deny from env=AUTHREQUIRED
Satisfy any
</Files>
That will require you to create a .htpasswd
file containing the passwords of all the valid users.
Here is an example of adding a “schacon” user to the file:
$ htpasswd -c /opt/git/.htpasswd schacon
There are tons of ways to have Apache authenticate users, you’ll have to choose and implement one of them. This is just the simplest example we could come up with. You’ll also almost certainly want to set this up over SSL so all this data is encrypted.
We don’t want to go too far down the rabbit hole of Apache configuration specifics, since you could well be using a different server or have different authentication needs.
The idea is that Git comes with a CGI called git-http-backend
that when invoked will do all the negotiation to send and receive data over HTTP.
It does not implement any authentication itself, but that can easily be controlled at the layer of the web server that invokes it.
You can do this with nearly any CGI-capable web server, so go with the one that you know best.
筆記
|
For more information on configuring authentication in Apache, check out the Apache docs here: http://httpd.apache.org/docs/current/howto/auth.html |