this might not sound too practical
but i want github collaborators to only be able to modify / make changes to the files that they themselves uploaded on the repository
they should not be able to replace, rename, edit or modify files uploaded by other collaborators in the same repository
is this possible to achieve in a private repository on github ?
If so, how can i do this ?
Git operates at a repository level, so if a collaborator can push to a repository, they can clone, modify locally any file and push back.
You can isolate their work through fork and pull request.
And use an GitHub action like check-new-commits (modify for your purpose) to check if each commits only includes files whose list of authors is limited to one.
Related
I'd like to know how to proceed in GitHub where I could to be able to get the updates from the original repo but prevent opening a PR after each time I push a change made by myself?
The concept I want to apply this is to use a blog template for my GitHub pages. I'd like to get the feature for the future if the contributors would make any but at the same time, I'd like to prevent pushing anything to the original repo as a PR since those commits wouldn't include anything related to making a contribution to the project.
PRs aren't generated automatically, you need to explicitly create them from a branch.
You can fork a repo and work on it, and when needed, fetch and rebase from the original repo you forked from. As long as you don't explicitly use this repo to create PRs on the original repo, you should be fine.
EDIT - Adding some details as per the last comment:
Assume there's a repo called something owned by someone. You can start off by forking it to youruser using the GitHub UI. Then you can clone your fork and work on it:
git clone https://github.com/youruser/something.git
In order to get the recent changes from the original someone/something repo, you need to set it up as a remote. By convention you'd call this remote your "upstream", but you can really give it any name you choose:
git remote add upstream https://github.com/someone/something.git
Once you've added it as a remote, you can fetch from it and rebase on top of it:
git fetch upstream && git rebase upstream/main
(note that using the main branch is just an example. You can of course rebase on top of any branch in the remote repo)
I think it's not possible because when you clone or fork that repo, from that time, you start to add your own content to it since it's your personal blog. So you cannot keep getting the features from main repo. Maybe you can try rebase but I'm not sure if it works for this case. Or you can add those features to your repo by your own whenever you need them.
In github, my account can access multiple related repositories. A user story can be implemented as same-name branches in multiple repositories.
Given a branch's name, can I find out which repositories contain a branch with the given name?
Can I further jump to such a branch in a given repository?
Probably the simplest way of searching repositories for branch names is to use the command git branch within each repo. You can specify git branch -a for local and remote branches, or git branch -r for just remote.
This isn't ideal for a number of reasons, one being that you'd need to have command-line access to all the repositories you want to search (such as all the repos being cloned locally), another being that you'll have to manually scan through the branch list that git branch outputs.
One possible solution to this is to use the GitHub API to list all repos and / or all branches. The answer here gives a decent example in Python of how to authenticate (to allow access to private repos), which you would need to follow with the API's GET request:
GET /repos/:owner/:repo/branches
I have a set of documentation for my company's API, based on the excellent Slate framework from TripIt. Per instructions, I forked their repo and proceeded to customize it. That fork lives here.
The obnoxious thing is that when contributors in my organization do a new pull request, the "base fork" on the Github "Comparing Changes" screen defaults to TripIt's repository, not my fork. They've more than once sent pull requests to the wrong place. Telling people "don't do that" isn't a particularly reliable solution. How can I set the default for where PRs are based to my fork?
GitHub keeps track of forks made through their interface and assumes pull requests will be for that original repository. You need to tell GitHub that your copy is not a fork but rather a regular repository that just happens to have identical history. Sadly, GitHub doesn't offer a good way to just uncheck the fork link. I typically solve it this way:
Clone the repository, git pull, and ensure your local copy is completely up to date.
Delete the repository on GitHub.
Create the repository on GitHub using the exact same name. Ensure it's an empty repository (don't create a README or LICENSE file.)
git push all the content back into the repository. (You may need to switch to each branch and push it, and you also may need to git push --tags.)
FRAGILE: This approach will lose existing GitHub issues and pull request comments. If you're using these heavily, this approach is probably a bad idea, and you should contact GitHub customer support to help you instead.
It is unfortunate that GitHub does not provide a way to configure the default PR target repo.
If you can delete (or get the owner to delete) the original repo A from which B was forked, then that will do the trick.
If it is not possible/agreeable to delete A, but the owner of A is willing to do the following, then the fork link gets broken, on GitHub Enterprise at least:
mark repo A as Private
mark repo A as Public again
After doing this, repo B (which was originally forked from A) will default to opening PRs against itself, rather than A.
Note: if A itself was forked from something further back in the history, then unfortunately it seems that B starts defaulting to opening PRs against that repo once A has gone. The only solution would be to apply the above to all repos upstream in the fork tree :(
Your other developers seem to have forked TripIt's repository, so that is the source/parent of their work.
In fact, if you open your own repository, you will see it hasn't been forked at all (the fork count is 0).
When they issue a merge request, by default github shows that repository as source, and so the pull request isn't sent to you.
The simplest workaround in this case is to ask your dev's to fork your repository, and work on it.
Yes, it's a bad situation...
The only solution I know of (other than deleting the fork and recreating/pushing directly from a local clone as described here ) is to have the upstream owner make the original repo PRIVATE and then return it to PUBLIC. Taking it private breaks the link to forks permanently.
But of course that requires action by the upstream owner. Github should really solve this, but it's been an issue for a very long time.
I have a Github repository, lets call it Repo A. I have two other users than need to push/pull changes from this repository. How do I go about doing this?
I have tried having one of the other users fork Repo A into their own Repo, lets call it Repo B, but when they make changes to the contents, it only pushes to Repo B, not Repo A.
I want the other users to have the changes they make locally push to Repo A.
You have two options:
Forget forks. Use branches. This is the simpler option. Everyone involved needs access to the repo.
Keep forks, use Pull Requests. This allows the owner of the repo to fully control whether changes are accepted or rejected.
Imagine situation like this:
You have a working repo in bitbucket - you were pulling revisions from another bitbucket repo in Windows 7 through TortioseHG.
Now the second project has moved to Github system and you can not pull from it anymore.
So my question is like this:
How can i somehow create new repo in bitbucket where I will pulling changes from github and from this repo i can easily pull in Tortiose HG to my working repo?
I do not want to use Github etc, so please do not advice it to me etc just help me with my question. Thank you.
The ideal solution consiste to keep local Mercurial repo, and work only with this local repo to the existing bitbucket Mercurial remote repo.
With a plugin like Hg-Git, you can at least push to and pull from a Git server repository from Mercurial, allowing you to pull from the GitHub repo to your local Mercurial repo.
From that local (Mercurial) repo, you can then work as usual with the bitbucket remote repo.
The OP adds:
It didn't work for me so i tried to transfer git repo to hg repo and from this repo pull to my working repo with changes - but it says that: abort: repository is unrelated - but I merged a lot from it. Any help here?
That makes senses, if both repos have been developed separately, you cannot push/pull 2 (mercurial) repos one into another.
This is confirmed at the bottom of the page "Understanding Mercurial", and detailed in the blog post: "What Mercurial Can't Do: Subtree Repos".
The more practical solution would be to make one extra repository (a "parent one") with your two repos declared in it as nested repository.
It would keep both repos independent, allowing to push back to the GitHub repo from your second mercurial repo.
If you don't have to push back to GitHub, but really want to have one repo in which you merge common files, then you can look in "Merge tip from an unrelated repository with Mercurial", but that is much more complex.
I would rather:
keep both repos separate
delete from the first one the common files you need to merge in the second one.
report and merge those common files in the second one.