I've recently been looking at using Git to eventually replace the CVS repository we have at work. However after watching Linus Torvalds' video on YouTube about Git it seems that every tutorial I find suggests using Git in the same way CVS is used except that you have a local repository which I agree is very useful for speed and distribution.
However the tutorials suggest that what you do is each clone the repository you want to develop on from a remote location and that when changes are made you commit locally building up a history to help with merge control. When you are ready to commit your changes you then push them to the remote location, but first you fetch changes to check for merge conflicts (just like CVS).
However in Linus' video he describe the functionality of Git as a group of developers working on some code pushing and fetching from each other as needed, not using a remote location i.e. a centralized location. He also describes people pushing their changes out to verifiers who fetch and push code also. So you can see it's possible to create scalable structure within a company also.
My question is can anybody point me in the direction of some tutorials that actually explain how to do this distributed development of code using Git so that developers push and fetch code from each other with out committing to the remote repository and if possible it would be very nice to have this tutorials Eclipsed based.
Thanks in advance,
Alexei Blue.
I don't know any specific tutorial about this. In general, for connecting to a repository, you have to be running a git server that listens (and authenticates) to git requests.
To have a specific repository for each developer is possible - but each repository needs that server component. It is possible to store multiple repositories on the same computer, that allows reducing the number of servers required.
However, for other reasons it is beneficial to have some kind of central structure (e.g. a repository for stuff to be released; or a repository for stuff not verified yet). This structure is not required to be a single central repository, but multiple ones with well-defined workflows regarding the data move between repositories (e.g. if code from the verification repository is validated, it should be pushed to the release repository).
In other words, you should be ready to create Git servers (e.g. see http://tumblr.intranation.com/post/766290565/how-set-up-your-own-private-git-server-linux for details; but there are other tutorials for this as well), and define workflows for your own company to use it.
Additionally, I recommend looking at AlBlue's blog series called Git Tip of the Week.
Finally, to ease the introduction I suggest to first introduce Git as a direct replacement for CVS, and then present the other changes one by one.
Take a look at alblue's blog entry on Gerrit
This shows a workflow different from the classic centralized server such as CVS or SVN. Superficially it looks similar as you pull the source from a central Git server, but you push your commits to the Gerrit server that can compile and test the code to make sure it works before eventually pushing the changes to the central Git server.
Now instead of pushing the changes to Gerrit, you could have pushed the code to your pair programming buddy and he could have manually reviewed and tested the code.
Or maybe you're going on holiday and a colleague will finish the task you've started. No problem, just push your changes to their Git repo.
Git doesn't treat any of these other Git instances any different from each other. From Git's perspective, none of them are special.
Related
first: We use a github repository in the team for some projects.
I'm using scripts defined in the pre-commit hook directory, locally (works perfect for my commits).
What I need is for every user (collaborator) to use the hooks without using symlinks or asking them to put them on their home folders.
Is there a way to set them up so the users can't commit if the scripts don't exit 0?.
Thanks.
As Henrik alluded to, in the Enterprise version, there is such a thing as the pre-receive hook. It runs server side and so you would not need to install it on each collaborator's local machine. But you are using github.com actual, and they don't allow pre receive hooks , nor do I expect they plan to; allowing indivduals to run scripts on their server isn't likely in their business plan. So that likely won't help you unless you are in a position to go to the enterprise product
There are some remedies you do have, however, but it won't be equivalent. You can , for example, set a protected branch . You could thereby make it only you can check into that branch, and you of course would be using the local hook, every one else would be using a pull request.
Additionally, you could look into LGTM (Looks Good To Me) or similar automated pull request approval system. I don't believe the official server is up but the source code is there and it could be run by someone else. LGTM allows you to set a number of different conditions that would be closer to an equivalent to your pre-op hook.
Setting up such a system might well be more effort than it is worth to you, understandable; but it is do-able.
The main problem with using pre-commit hooks that come with git is that they are local to your repos and don't get pushed to github.com. I believe under the hood, those hooks aren't even transferred up to the repo on github, and that the pre-commit hook directory itself is not available like it is on the local copy of a git repo.
(I would say more on that architecture of the pre-commit hook dir except A. I am not sure if it is covered by NDA and B. I only saw the way it was on the Enterprise product, not github actual, and C. I don't know if the structure is still exactly the same)
We are using Eclipse with a SVN client plug-in. This client needs a server running; what about Git? We need to work in a LAN environment without internet access. I have read some basic tutorials about using Git with Eclipse. If I got a Java project in my Git repository, how can I share it with my teammate?
Even though you can share your local repositories, I would suggest setting up a server. There many free alternatives like:
gitlab (http://gitlab.org)
gitorious (http://gitorious.org)
gitolite (https://github.com/sitaramc/gitolite)
gitblit (http://gitblit.com/)
But IMO the best one is Atlassian Stash which for small team will cost you only $10.
if you need to share it, you need some way to access it from each other. Bitbucket is great for small teams who need private code.
If you are always using it from inside a LAN one of you should set up a shared section which you can all push your git changes too (a shared folder or shared drive is good enough) but i would recommend using github / bitbucket if possible
from a command line (can probably use it within eclipse too)
git clone file:////192.168.1.100/code
and then you can psuh and pull from 192.168.1.100/code assuming you have write permissions there
if you're coming from subversion to git, you will be faced with the concept of local repository vs shared repository. You will be able to have a local repository on your computer where you can do as many commits as you want and then only push relevant changes to the shared repository (the one that your teammates will be able to see).
Here's an useful link on the possibilities to share a repository: http://www.jedi.be/blog/2009/05/06/8-ways-to-share-your-git-repository/ (ignore the last one, GITHUB, which will require internet access).
In your particular situation I would recommend sharing via SSH or via GIT daemon.
I also really recommend you to take a look on Eric Sink's book here. He's even offering hardcopies for free!
as suggested you can run your own instance of gitolite or gitlab, but for a rudimentary solution i suggest you just check the following answer:
https://serverfault.com/a/113688/181010
basically you can use any folder as a shared repository as long as all users can access the files either locally or via ssh. that link discribes how to tell git to create its file with rights that are appropriate for usage by all users of one unix group (instead of only the single user owning the files).
I am working on setting up a development/deploy cycle for one of our latest projects. Here is what I am trying to do,
Commit the latest code to local "mercurial" clone.
Push it to central repo hosted at "bitbucket"
Open some web based management console (this is the part I need help with) on my server, which is already configured to use the bitbucket repo automatically fetches the latest commits and shows a list.
Choose one of the revisions and perform an update which will effectively update the website.
If there are some issues with the latest revision, go back to previous version using the same web console.
I am using "SourceTree" for step1 and step2 and I want to keep the whole cycle GUI based. Can anyone suggest any tool which I can use for the server side management (step 3,4,5) ?
This is more simple than you'd think:
Clone the website on your server using bitbucket as the source
Write a small web app which calls hg pull -u in the root folder of your website. Mercurial remembers where to pull from, so you won't need anything here.
The second feature can be implemented using hg id -i (see this answer) to get the current revision. Write that to file.
Now you need a web page which lists all the revisions in that file and runs hg up -r <revision> when you click on one of them.
But maybe a better approach would be to push directly to the web server using hg push from your local repo (see here). You can then use a hook to update the files and save the last revision to a file.
Now you'll only need a web service to revert to a former revision.
Team City is a web app which can do that for you.
It is a continuous integration server but can be configured to only publish when you use the application.
There are many continuous integration servers and I imagine that most/all can do what you want so search around if that one doesn't quite fit your needs.
how would one protect a GIT repository of a complete (java) application from having a developer getting access to all the source code in the repository. I know GIT is a distributed Versioning Control where a developer normally "downloads/fetches" the complete(!) repository.
My Questions:
How to sperate "modules/autonomous parts" in git? For example havng a module "payment layer" and "database layer" and "processing layer" and so forth all abstracted via APIs/Interfaces. Do i have to setup a seperate git repository for all those modules?
Is there a way to have one large repository in GIT but to somehow restrict the access by path? (A client should only recive those files he was granted access to)
Is there a way to have one large repository in GIT but to somehow restrict the access by Branch/Tags? (A client should only recive those files he was granted access to)
Just in Case someone knows this too: Is there a way in eclipse to chekout content from multiple GIT repositories into one project and also (the other way round) commit code within in one eclipse project to multiple different GIT repositories (based on package names/paths or in the context menu)?
Thank you very much
Markus!
You will have to split up the code into multiple git repositories if you want differential control. You cannot control by branches or whatever. Git downloads the entire repo. Period.
You can look into git modules for a mechanism for making it easier to work with a thing built of multiple git repositories.
1) and 4) depends a lot of your build evironment. In git you try to have separate repositories per modules, but if the setup of the source tree becomes painful you can use git submodules (though not much people like them) or the repo tool the Android project uses. This allows you to have an "umbrella" project composed of more subprojects. Not sure if it is worth it for just a few components. Just one git repo may still make more sense.
For questions 2) and 3):
For access, I would recommend that every sub-team keeps its own fork (repository) and somebody reviews what they push to the integration repository. If you don like this approach, you can use git server hooks to enforce policies writing scripts.
In this case, the hook could check who is pushing, and the path or refspec (branch) against some config file describing the policy. This is documented here:
https://git-scm.com/book/en/v2/Customizing-Git-An-Example-Git-Enforced-Policy
1). Look at Git submodules http://linux.die.net/man/1/git-submodule
2,3). Look at Gitolite https://github.com/sitaramc/gitolite/blob/pu/doc/gitolite.conf.mkd
4). I don't think any eclipse-git plugins allows that. However, you can use an external/command-line client to achieve what you want.
The question
An open source program uses CVS for version control. I would like to make a number of bug-fixes and submit patch bombs to the developers with commit access. I would also like to maintain my own semi-private fork that mainly tracks the main code-base but that includes my own features (these features, right now, should not be incorporated into the main code-base.)
I prefer to use mercurial for my own version control needs, but I am open to other version control systems if necessary.
I'd like to:
Be able to easily create patch-bombs against the current CVS source with my own bug-fixes
Keep track of history on my own features
Have fixes and improvements from the main tree easily incorporated in my new-feature fork
Easily apply my own bug-fixes to my new-feature fork
Be able to work and track change history without an Internet connection.
What suggestions do you have for doing this?
My current idea
My own best guess is below, to give you a better idea of what I am thinking about.
I will have 3 mercurial repositories.
The first two repos are managed as specified at (https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS). One just mirrors the latest changes from the CVS upstream. I do "cvs update" then "hg commit" in this repo. The second repo holds my bug-fixes as patches using the mq extension and I pull from the the first repo and re-base my patches every so often. When my patches are incorporated into the main tree, I remove the patches from the patch queue/make them permanent commits.
The third repo is my local fork. It will start out as a clone of the first repo. Then each time I do an update of the first repo, I'll pull from it into repo 3. My own features will be directly present as commits in this repo. When I fix a bug, I'll export a patch from repo 2 and apply it to the appropriate pull from repo 1.
I have used Git to manage changes on top of a CVS repository in a similar way. My solution in Git uses local branches instead of multiple repositories, but it sounds essentially similar to your proposed idea.
I found that this arrangement works best if you commit all the CVS metadata (in the CVS/) subdirectories) to your mirrored repository. This means that the CVS metadata gets replicated in the other repositories, but it doesn't cause any harm (and lets you run commands like cvs diff if you need to).