With GCP CSR, is it possible to change the default branch for a repository from master to something else? This doesn't have much bearing on functionality other than the branch that's first displayed in the CSR UI. However, it's something I can change in GitHub.
No, you cannot change the default branch from master to something in Google Cloud Source repository. However, a trick that I use to reach my branch in the UI directly is by following this link:
https://source.cloud.google.com/<project-id>/<repo-name>/+/<branch-name>
git config --global init.defaultBranch <name>
should do the trick
Related
I've been looking for a way to automate a task, one manual part that needs automation is this restore branch button, is there a way to do this using Github API? I've read these two documents and couldn't find anything, Thank you.
https://docs.github.com/en/rest/reference/pulls
https://docs.github.com/en/rest/reference/branches
Following off the advice from here: git can I view the reflog of a remote?
I was able to restore a PR branch via the GitHub CLI/API by...
Getting the SHA of the HEAD of the branch to restore with:
gh pr view {pr_number} --json commits
where the last commit in the "commits" array will have a "oid" value (which I believe stands for orphan id), and that can be used to create the restored branch with
gh api repos/{owner}/{repo}/git/refs -f ref=refs/heads/{new_branch_name} -f sha={oid}
# set new_branch_name to the name of the PR branch to keep same behavior as button
and now the branch can be fetch'd when within a cloned instance of the repository:
git fetch
but is also available via API as there is now a new remote branch
Sorry if you can't use gh. This worked for me and I don't mind the dependency. If someone likes they can figure out a full REST API only way.
I've searched some documentation but couldn't find exactly what I was looking for.
Does GitLab provide a feature which allows deleting all branches which have been merged recently? Either as a feature of GitLab itself or by using a third-party plugin or similar?
Gitlab exposes API resource to delete all non-protected branches merged into the project’s default branch (master per default).
To delete them periodically in gitlab, you can create a pipeline in a .gitlab-ci.yml and schedule it at the frequency you want.
Have you checked https://docs.gitlab.com/ee/user/project/repository/branches/#delete-merged-branches? Also, there's an option to remove the source branch automatically after it's successfully merged into master.
I have some projects set up on GitLab Cloud, complete with issues, wiki pages, etc. I've recently set up an internally hosted gitlab instance. I'd like to bring these projects over from GitLab Cloud to the internal GitLab instance.
Bringing over the git repos seems easy enough (change the remote and push), but I don't see how to bring over the wikis and issues.
In general it seems like this isn't possible. (There's a GitLab Feedback for it here.)
However, the project wiki's seem to be their own git repos, which you can see on the Git Access tab. While that doesn't solve issues/snippets, it gets you part of the way there.
I don't know how to transfer over issues as I have not had to do that yet, but passing over the wiki is not that difficult.
On your old gitlab instance you will notice two repositories for your project (let's pretend your wiki is oldproject), one will say something like oldproject.git and oldproject.wiki.git.
The general path to the repositories where you can see the names I am talking about (let's assume user-name is "myaccount") can be found here:
/home/git/repositories/myaccount/
or (if using the omnibus installer):
/var/opt/gitlab/git-data/repositories/myaccount/
I presume you already know how to transfer over oldproject.git. You do the exact same thing with the wiki, only you create a bundle file out of oldproject.wiki.git:
git clone http://gitlab-instance-ip/user-name/oldproject.wiki.git
cd oldproject.wiki
git bundle create oldproject-wiki.bundle --all
Now initialize your new project in gitlab...I presume you already know how to do that as you suggested in your question that you know how to import the files from your project over to the new instance without problem. Now repeat for the wiki:
git clone http://new-gitlab-ip/user-name/newproject.wiki.git
cd newproject.wiki
git pull /path/to/oldproject-wiki.bundle
git push -u origin master
I had a very similar problem to yours where I didn't see that anything was actually "pushed". When I went back to the gitlab project I noticed that it was in fact updated with the wiki. See here if you think it will help: Importing Gitlab Wiki to a new Gitlab Instance
Good luck!
We're using GitLab for our project and we think it's great.
We're also using git flow to manage the changes in feature, develop, master branches.
Can you use the Merge Request build in GitLab to manage the branches in git flow style?
Meaning when accepting a Merge Request for a release branch, it will merge the release branch into master AND into develop..
Or should we always use git flow on our local machines to accept the Merge Requests.
Like this issue 1628 illustrates, it is best to use GitLab to publish (push) branches, then to rely on a specific GitLab feature related to a particular workflow like git-flow.
So the natural approach is to limit those git-flow features to the local clones, and push any branch you want to GitLab once the merge request is resolved.
By now, there is something called GitLab Flow, "a clearly defined set of best practices".
Cited from the linked source:
It combines feature-driven development and feature branches with issue
tracking.
We are working on a project in a 3 people team. We don't have yet a separate machine to set up a Git central server so we have to get along without it. We will have the machine in a few days so I treat the curent workflow more like an experiment. So now we do like this:
1) every member is creating a git repository on his computer simply like this:
git init
2) every member makes his repository readable by others like this:
in .git directory:
touch git-daemon-export-ok
And then:
git daemon &
3) every member sends address of his repository to other members and every member imports it like this:
git remote add aa git://xxx.xxx.xxx.xxx/home/username/code
Now when the initial setup is done our workflow looks like this:
We checkout to the dev branch on our local repository to do the work. When we're done, we pull other members' master branches into our repository:
git pull --rebase aa master
git pull --rebase ab master
...
Finally we squash commits from our dev branch if necessary and merge them with our local master. From now on other members will be able to download these commits form our computer into their masters.
What do you think about it?
#
I should add that this is happening in the company and we are not allowed to use Github or something like this here. Our software is going to be open source but we have to follow strict security policy.
I believe if the team is self disciplined there shouldn't be any problem, but definitely treat this a a temporary solution, because if the team increase will be much harder to avoid problems. Btw maybe think about github private repository. They work like a charm.
Seems rather a convoluted solution to me. So why not just use a hosted service temporarily, and move to your own Git server when it arrives?
Obviously, GitHub is the 800-pound gorilla in the room here, but I personally use BitBucket in a professional capacity because unlike GitHub, it offers free private repositories (but limited to five users).