Persistent URL for GitHub repo subfolder - github

I would like to provide a URL to a subfolder of a GitHub repo in a paper I am about to submit. I thought the link should look like github.com/account/reponame/folder/subfolder, but I realised now that when navigating through the repo, I need to write github.com/account/reponame/tree/main/folder/subfolder for the link to work. Can I assume a link with this format to be persistent, or is there a better way of ensuring that the URL is useful for a long time?

the /tree/master/ just indicates the master branch is being accessed. The link would be active till someone with edit access to the repo changes the folder structure or deletes it. If it is a repo with shared edit access, I would suggest you to fork it and make it private and then share the link from the fork so that no one would make changes to the path other than you.

It is safer to refer to a specific commit, that is:
github.com/account/reponame/tree/COMMITID/main/folder/subfolder
Where COMMITID is the SHA hash of your commit, which should look like 56e05fced214c44a37759efa2dfc25a65d8ae98d
That way, you can still push changes to your repo, and the reviewers still will get access to the specific version you want.

Related

How to remove "generated from" tag?

I see this message below my repo name. Is there any way to remove it? I used template for my app for a quick start, but in current form my app doesn't look like this template, because everything changed so much. I don't see any reason why it's still there.
I had the same problem and at the time for writing this answer, there is no option of removing this from Github. So removed this tag by deleting the repository from Github and recreating a new one with the same name.
⚠️ This operation will preserve only the information stored in git, not all other Github features, i.e. issues, PRs, ... If your repository has been used for a while, this might not be the right time to do this anymore.
Specific instructions:
Make sure you have cloned your repository and all your non-stale branches are saved locally.
git fetch
Delete the original repository in the Github web UI.
Create a new repository with the same name.
Push the branches you want back to the remote.
git push

Can I make sure no one forks my GitHub repo but still allow the work to be seen by recruiters?

I am now building portfolio to get my first tech job. I would like for any recruiters/potential employers to see my code in case they want to see how I am putting things together but I don't want anyone to be able to fork or copy my work.
How is this possible?
If I have a private GitHub repo does that mean that you can see the repo but just not the inner contents? I have looked at the GitHub documentation already.
If I have a private GitHub repo does that mean that you can see the repo but just not the inner contents?
If you can access a repository (public or private), that means you can read its content and/or clone it (and read its content locally)
You would need to setup a private repository dedicated to show your file
names, meaning a collection of files with:
dummy content
the exact names and folder structure than your actual projects.
That way, you can share to select collaborator access to that "showcase" repository, without compromising the sensitive content of your actual project repositories.

Exclude files from the new pull request (github)

Bitbucket has a feature to exclude files from the new pull request and I'm wondering if there is a similar feature in GitHub?
Scenario:
I have a Branch A that has changes in .travis.yml I pushed those
changes and create a PR I need to merge all changes in this branch
except the changes in .travis.yml file.
No, there is no such feature in GitHub (to the best of my knowledge confirmed by a quick google search).
The best alternative, excluding the proposed duplicate question for using a workaround, is to refer to this blog page, stating that:
Previously, if you wanted to use GitHub to remove files from a pull
request, you’d need to switch to the pull request branch and look for
the individual file to delete it. Now, if you have write permission,
you can click on the ‘trash’ icon for a file right in the pull
request’s “Files changed” view to make a commit and remove it.
I haven't tested this method, but I feel like it is somehow related to the rejected "alternative workaround".

Rename a github repo temporarily?

I found the steps to rename a github repository. My question is whether I could rename it and then change the name back to the original name. I read that github will do some redirects, so I was concerned before doing it that it would not allow me to rename it back to its original name.
Here is my scenario: I'm have a course that has an associated github repository. People are currently watching the course and need access to the github repository with the current name.
I am working on an update to the course which has a slightly revised name and hence I want to rename the github repo. For today, I want a screen shot of the newly named repo. But I can't officially (and permanently) change the name until the updated course is done and ready to go live.
No, GitHub will not block you from changing the name of the repository back to what it was previously if you have to temporarily change it like this.
I just tested it myself, was able to rename my repo right back to how it was previously.

How to check out file in Git?

I just started using github.com and my friend and I are working on a project. How can I pull parts of the project but check out certain files I'm working on so he doesn't work on them. He can still download the files but he won't be able to open or edit them until I upload them back and give permission?
I suppose you mean lock a file when you edit it. Git won't let you do this and it's not something you need to worry about. Instead, you can both work on the same file and then merge your changes later.
If you really want to work that way (i.e: lock files, or at least control when your friend will modify your repo), you can ask your friend to fork your repo.
That way, he/she:
will have his/her own copy of said repo
will work on any file
will rebase first with branches fetched from your repo (added as a remote on his/her fork, as described in GitHub: working with remotes)
will make pull request, allowing to decide what to include and when.
Historically version control systems provide a checkin/checkout feature. When you do a checkout, you reserve the artifact. If another person also has the same file checked out, then you get an error when trying to checkin the artifact. Not sure creating another fork is really the equivale