My team is increasing its usage of git and we'd like to start using a public branch, so that users can do their integrations/merges there, instead of master. How do I make a public branch?
Yes, I am a noob at this. Thanks for your help! :D
My team is increasing its usage of git and we'd like to start using a public branch, so that users can do their integrations/merges there, instead of master. How do I make a public branch?
Yes, I am a noob at this. Thanks for your help! :D
It depends on the scope of the group of developers to which you want to give access to the repo. If you are talking about an internal group, any repo you have on a server accessible by your employees is enough, as the branches will be there. In which case, the advice from @khmarbaise is accurate. Then, your users can fetch that branch, branch from it, you may merge those branches accordingly through a CI like Jenkins, etc.
On the other hand, if you're talking about open source then you could create a new public repo on github, bitbucket, or any other git host, and simply point your users to the repo. Users would create branches from the master branch of this repo and either push directly to master (yikes!) or submit their own branches/Pull Requests.
If you intend to impose branch-specific permissions then a server-side authorization layer is required, such as Gitolite (or others: http://alternativeto.net/software/gitolite/). With Github, one could control write access to one repo, allow users to fork their own, and merge Pull Requests being submitted.
You have to create the branch as usual:
git checkout -b TheBranchToUse
Afterwards you need to make it public to others:
git push -u origin TheBranchToUse
It depends on the scope of the group of developers to which you want to give access to the repo. If you are talking about an internal group, any repo you have on a server accessible by your employees is enough, as the branches will be there. In which case, the advice from @khmarbaise is accurate. Then, your users can fetch that branch, branch from it, you may merge those branches accordingly through a CI like Jenkins, etc.
On the other hand, if you're talking about open source then you could create a new public repo on github, bitbucket, or any other git host, and simply point your users to the repo. Users would create branches from the master branch of this repo and either push directly to master (yikes!) or submit their own branches/Pull Requests.
If you intend to impose branch-specific permissions then a server-side authorization layer is required, such as Gitolite (or others: http://alternativeto.net/software/gitolite/). With Github, one could control write access to one repo, allow users to fork their own, and merge Pull Requests being submitted.
I had the same problem in a teaching context: have the exercises and solutions for other professors and TA, and also have a "public branch" for students to download at first exercices, and then solutions after session hours. My solution using github:
In the current install, I have:
$ git remote
cours
cours-public
$ git remote get-url cours
[email protected]:YannickChevalier/programmation-en-C.git
$ git remote get-url cours-public
[email protected]:YannickChevalier/programmation-en-C-CUPGE.git
$ git git branch -a
configuration
enonces
* enseignants
solutions
solutionsprof
Say enonces is the public branch and solutions is the private branch on which you do all the work and create the files. You update the public branch by using checkout from the non-public ones, such as
git checkout enonces
git checkout solutions -- *.pdf
git add .
git commit -m "update of solutions"
git push cours-public enonces
Note however that this solution is not perfect: git doesn't handle the meta-data of the files, which means that after this operation, it will assume it has to recompile everything because the LaTeX source files and the pdf are wiped and restored. You will have the same problem unless you set up 2 local directories: one for the compilation that stays on the same branch most of the time, and one set up specifically for the exchange between the public and private directories, and on which you never compile.
© 2022 - 2024 — McMap. All rights reserved.
git
, a branch is a branch. There's no distinction between "public" and "not public" other than how you use them. It's just a branch. – Affettuoso