We build a project for a client. This project is hosted on a private repo where each branch is assigned to a different client.
We would like to grant a given client the right to see what's on his branch, without seing everything on the repo.
Is that possible ? Other possible solution ?
Thxandregards.
I don't believe there is a "clean" method for what you're looking to do.
Depending on how you want to communicate things you could make use of the Slack integration and the branch by branch filtering concept that has been raised.
https://github.com/integrations/slack/issues/441
I question why your projects are a branch per client and not repo, (maybe the private repo cost?). In any case, if there are subtle differences between client projects can the main source code be parameterized so if multiple clients see the same files they don't actually know anything about your other clients?
Related
Is there any easy method to push\upload a file to multiple github repositories at once?
without need to first clone them to local machine. kinda script or cli\gui tool?
I searched across Google, but seems nobody asked\wanted the same thing..
What i trying to achieve is to upload a new renovate.json config to all my repositories under one github account (some of them public, some private, more than 60 repos at all)
What you request is an error prone method. For example, How do you expect the tooling to resolve merge conflicts when they occur in multiple repositories?.
If this file is indeed a shared component. I would recommend to use submodules.
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)
Can anyone please consult me on one thing?
We have a project, and we just decided to hire more programmers to work on it.
Up to now I was the only programmer, backing up the code on GitHub.
But now I need to find a safe way how to manage multiple programmers.
So there is a master branch of private project, which other programmers should be able to clone.
But they should not be able to commit changes to master branch themselves.
Perhaps they should make their own branches, and commit changes there.
And I should be the only person who is able to review their work, and merge it to master branch if it works right.
Can anyone please tell me how exactly I should set it up?
Or send some good tutorials?
Thanks so much
Collaborative coding is rather the whole point behind Github. Here's an illustrative workflow to get you started. A similar development flow is absolutely essential to open source projects (which by nature must work via the internet). In fact, a lot of open source projects use Github. You can use this process, too; although there are some caveats, which I've listed at the bottom.
The key to understanding this workflow is that each developer will manage 2 repositories:
Personal work, on their local machine
Work visible to all participants, hosted by Github.com
Setup process, integrator (project lead):
Create github account
Host project there
Setup process, developer:
Create github account
Fork the project
git clone forked branch to local machine
Development process, developer:
Work on local copy
Push to github copy. (Remember, each developer has their own Github branch.)
Submit a pull request to the project lead's Github repository.
Rinse and repeat.
Development process, integrator:
Look on Github for pull requests
Review them, approve them, merge them
Work on local copy, as above, sans the pull requests
However, this isn't the only possible workflow. For example, Github makes it convenient for your developers to send pull requests to each other, e.g. if two of them are working together on a feature. This way, all of them may work in the "integrator" role somewhat.
Caveats:
If your program is not open source, then there is one caveat to using github: you must pay to host private repositories. They have a mechanism (disclaimer: never used) for organizing collections of people to work on either public or private repositories, however, and I believe the cost can be paid entirely in the organization owner — which would be great for your developers, and cost some extra for you.
If you only have a few contributers, you might be able to get by with having a free private repository by using Bitbucket instead of Github. They have an option to host private repos for free, and the workflow would be about the same as what I've outlined above.
The best way to achieve this is with a pre-receive hook which looks at the username of the person carrying out the commit and the branch they are trying to commit to. If the username isn't in a list of allowed users and the branch is the master branch then deny the push.
e.g.
#!/bin/bash
allowedUsers=( 'bob' 'john' 'george' ); # list of allowed usernames
while read oldrev newrev ref ; do
echo ${allowedUsers[#]} | grep -q $(whoami);
if [ $? -eq 1 ] && [ "$ref" = 'refs/heads/master' ] ; then
echo "You are not allowed to push to master branch";
exit 1;
fi
done
When working with GitHub the best and easiest way is to use Pull Requests. In your case every programmer is given only Pull access to the repository, and has to cone it. When he or she is ready with the changes, that programmer sends you a pull request. You then review the request, and if ok merge it into the main repository.
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.
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.