<p>I have my GOPATH as a single git repo. I'm lazy and I like being able to use do a git pull and have all my little projects and utilities with me right away.</p>
<p>But that also means that my git history is kinda cluttered. How do you guys manage your code? What are the advantages and what makes it worth the convenience tradeoff of having just one giant repo?</p>
<hr/>**评论：**<br/><br/>mfcochauxlaberge: <pre><p>I have one repository per project and that's how it should be done, especially if it's public.</p>
<p>If you want to pull everything automatically, then make a shell script or something like that.</p></pre>alecthegeek: <pre><p>IMHO it helps to have a neatness fetish when programming.</p>
<p>a) I use scripts to automate the install of Go tools in one location</p>
<p>b) I use scripts to set up each of my projects in a separate GOPATH. Because I use the z utility this is easy and saves a lot of clutter.</p>
<p>So each module (or closely coupled group of modules) will have it's own Repo.</p>
<p>This stops my head exploding with the complexity of lots of mixed up things -- benefit!</p>
<p>And because I try and automate as much as possible it does not feel like I am losing any convenience.</p>
<p>(caveat -- I do not program large things)</p></pre>calebdoxsey: <pre><p>I have one repo per project and set my GOPATH to HOME. Then when I run <code>go get</code> binaries end up in <code>HOME/bin</code>.</p>
<p>If you wanted to you could still put all of your projects in one git repo (<code>github.com/borring/whatever</code>) and run <code>go get github.com/borring/whatever/...</code> to pull it all down.</p>
<p>Storing <code>pkg</code> and <code>bin</code> in git seems wrong though.</p></pre>hlandau: <pre><p>I have one GOPATH on my system, which is not a repository.</p>
<p>I have two types of repository: Go code repositories, which directly contain *.go files, and Go environment repositories, which contain other files.</p>
<p>Projects which build executables, rather than libraries, generally have a corresponding environment repository. These may be named <project>.t, where <project> is the code repository. Environment repositories typically contain any documentation files, configuration file examples, HTML template files, etc. They contain a simple Makefile which does the following:</p>
<ul>
<li>If a GOPATH is already set, use that. Otherwise, set the GOPATH to this directory.</li>
<li>If the GOPATH is not set to this directory, symlink {bin,src} to $GOPATH/{bin,src}.</li>
<li>Run go get <project> if it hasn't been run yet (this is recorded by an empty file named .gotten)</li>
<li>Run go install <project></li>
</ul>
<p>This has some advantages:</p>
<ul>
<li>People familar with Go can work with the code repositories how they like, and use go get.</li>
<li>People unfamiliar with Go can just clone the environment repository and run 'make', even if they don't have a GOPATH set. This is easy to explain.</li>
<li>The structure of repositories imposed by the go tool is quite suboptimal for repositories which need to contain lots of documentation, templates, assets, etc. These can go in the environment repository, keeping the code repositories clean. Since some of these assets may need to be built via makefiles and non-Go tools, some build scripts would be necessary in any case; this keeps them separate.</li>
<li>If someone doesn't like the environment setup, they can customise it while still using the same code repository.</li>
</ul>
<p>There are some disadvantages:</p>
<ul>
<li>Two repositories to keep track of, commit, push, etc.</li>
<li>./bin/ points to $GOPATH/bin/, which means that depending on how you design the program, it will consider the directory above the directory containing the executable to be either $GOPATH or the environment repository. This requires some care if this is important, e.g. if it uses executable-relative paths like $BINDIR/../tpl/ to find templates. If you get the executable name via abspath(dir(argv[0])), this works fine. If you realpath argv[0] or use something like readlink /proc/self/exe, it doesn't.</li>
</ul></pre>flynnguy: <pre><p>First, having one giant repo makes it very difficult to share one project with anyone. Say you develop something that's really cool and you want to share it with others, no one is going to download your entire folder of source code for one project.</p>
<p>Another advantage of separating things out is that when you look at your git logs, you don't have to parse out the other projects to find what you are interest in.</p>
<p>I understand the desire to have a simple command to initialize your development environment so what I've done is I have a setup script that I run. I keep these things in a ~/bin/ folder that I have in git that also includes all my dot files. In this setup script, you could easily make your GOPATH dir and then checkout all your individual projects into it. My usage is more for setting up a new computer so I have a lot of other steps (like installing go). I personally don't actually do a git clone on all my repos, I just clone them as I need them but it would be easy to add.</p>
<p>Sure, it's a little more work to maintain because every time you add a new project, you'll have to update your script, but I think the benefits outweigh this minor inconvenience.</p>
<p>You could also take a look at <a href="http://git-scm.com/docs/git-submodule" rel="nofollow">submodules</a> which would allow you to create one repo called say "go-projects" and then have all your submodules to that repo be your individual projects. </p></pre>dermesser: <pre><p>Another way of doing it that may be useful if you have many small-ish packages in your GOPATH that are non-public and developed more or less independently - think a larger web app -, you can check in your whole GOPATH in one git repository and develop in different branches. From time to time you can create releases and merge everything back into master.</p>
<p>This may or may not be a useful approach (I haven't tried it, at least not in Go), especially if you're an individual contributor it might be too much overhead. Otherwise it can provide you with a bit more stability by having explicit releases.</p></pre>kardianos: <pre><p>Many people will say that's wrong. I disagree. When you commit prefix with the folder you are committing to:</p>
<p>proj1/pkgA/subpkg1: make it so much better!</p>
<p>Yes, people will still pull your project. Some vendoring tools have the restriction that they vendor a repo at a time and say "everyone MUST make a repo === project". Again, I disagree. Other vendoring tools will pick the packages you need and ignore the vendor repo structure or repo size.</p>
<p>Do what makes sense for your situation, company, project dependencies. The trouble in this space is some don't acknowledge other viewpoints and use cases exist outside their own.</p></pre>
