Let's say I have a branch named feature/1. And also issue #1. I want to link that branch to that issue.
Is there a way to link that branch to that issue from the issue? Without making a commit.
Directly from GitHub:
References
Certain references are auto-linked:
SHA: be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
User#SHA ref: mojombo#be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
User/Project#SHA: mojombo/god#be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
#Num: #1
User/#Num: mojombo#1
User/Project#Num: mojombo/god#1
It seems that directly (as in user/repo/branch) is not possible, but maybe by using the id of the tree?
As mentioned in another answer, GitHub automatically makes links to various things, including other GH repositories, but not to branches within those repositories. When I want to do this, I manually make the link like this:
[a link to a branch](/_user_/_project_/tree/_branch_)
Where _user_, _project_, and _branch_ should be replaced with the parts of the branch's URL. For example, a branch in GitHub's "linguist" project:
[api-changes branch in github/linguist](/github/linguist/tree/api-changes)
Important:
GitHub's Markdown processor creates links using the exact URL value enclosed within parentheses. You must specify the URL considering how a browser would handle that link. If the URL specified is only the path portion (as in this example), browsers will treat the path as relative to the current page's URL. If that relative path begins with a slash ("/", also as in this example), then it will be relative to the root of the server of the current page's URL. Otherwise, paths that don't begin with slash will be treated as relative to the parent of the current page's URL. (This is basic HTML link specification.)
Do not forget to include the tree part of the URL when referring to specific branches of projects.
Since Sept. 2022, you can link a branch from an issue.
Nov. 2022, since gh 2.19.0 and the gh issue develop command:
$ gh issue develop 123 --name "my-branch" --base my-feature # create a branch for issue 123 based on the my-feature branch
$ gh issue develop 123 --checkout # fetch and checkout the branch for issue 123 after creating it
$ gh issue develop --list 123 # list branches for issue 123
$ gh issue develop --list --issue-repo "github/cli" 123 # list branches for issue 123 in repo "github/cli"
$ gh issue develop --list https://github.com/github/cli/issues/123 # list branches for issue 123 in repo "github/cli"
But, as noted by NotX in the comments (in Dec. 2022):
The new linking feature won't work for branches in other repos though.
So if you have a dedicated issues repo holding the issues from all the other repos, you've still go via mentioning.
Note that from April 2013 ("Branch and Tag Labels For Commit Pages"):
Any commit can mention the branch it is part of:
If the commit is not on the default branch, the indicator will show the branches which contain the commit. If the commit is part of an unmerged pull request, a link will be shown.
That means referencing a commit from the issue will allow the user to see the branch (by looking at the commit), and even to see a link back to the issue (still by looking at the commit).
You can't reference the branch directly.
But you can make a reference to a branch compared to another branch. If you enter this:
https://github.com/user1/repo/compare/branch1...branch2
it will render as
branch1...branch2
Also, you can compare branches across forks. If user2 has forked repo, this works:
https://github.com/user1/repo/compare/branch1...user2:branch2
I was looking for the same possibility in Git, but nothing was available so I decided to directly refer the brach with a markdown link by using the Hash reference.
# Issue02
## Commit Hash _<hash_number>_
...Rest of comments in the issue...
So, now in my organization we always do that reference when opening or closing an issue. It must be refered to a certain Hash and indirectly it is refered to the corresponding branch.
I guess you already now, but if not, to get the hash you will use git log
Note: It is not referencing to a certaing branch but a commit,
With some hours of work I think it is possible to automatically do this and create a command line tool,
Related
I thought the default head branch was now called "main", but today, I noticed in a new repo, the default branch was still called "master". But when I wanted to rename it, the popup told me that I should use main?
My colleagues did see main as default, so I'm wondering, why don't I? Am I using an old version or something?
Although I don't see what repo is this related to, what you experience is most likely seeing your own fork instead of the upstream repository.
If your colleagues see main as the master branch and you see master on your side, check whether you don't have your username as a prefix in the repo URL or title (that'd be your fork) and instead try to navigate into the upstream repository (the one without your username as a prefix).
Unless you use a GitHub desktop client the version will be the same as your colleagues have because it's being served by the GitHub servers for all the users (kind of, ignoring A/B testing, load-balancing, CDN, etc) and only GitHub can change the version.
If you use the desktop client, always try to update first before opening tickets/questions as issues might have already been resolved
We recently moved to git from svn (both using Eclipse). I am in the (perhaps bad) habit of writing my Java code first, getting everything to work and then going back and adding comments. In SVN this was easy. I would just create a Fisheye review with my Jira task. The review would have a list of all the files I changed and methods I added or modified. I would note it and abandon the review. Then I would edit all the files listed and add the comments.
However, Fisheye does not (I believe) work with git. I could do a git status to see the files I changed but the local branch is already updated so it will not list any files. And all it does is tell me I am something like one commit ahead of the remote branch but does not list any files.
Is there some way to see a lit of the files I have changed with git so I can add comments? And when I say I wait for my comments I really mean mostly for added classes and methods. If I do something like add a line or two to a method I will generally add the comment too.
changing comments on git commits is not that easy. Each git commit has a sha-checksum which also includes the previous git commit. If you change a commit you change the current commits sha-checksum. therefore you create a new commit. All following commits of your branch must now be rebased on top of this new commit.
The command line provides the git rebase -i [commitid] where you can do lots of modifications including changing comments on commits. I never did this with a GUI but egit might support that too. Just refer documentation on egits rebase feature.
I found out how to do this.
The "Synchronize Workspace" in eclipse appears to show all the changed files not yet pushed remotely. I have not done any pushes, so this showed me what files changed.
I have successfully been able to "diff" two files using the stash git API, however, each time you have to specify the full hashes of the commits, like so:
rest/api/latest/projects/{project}/diff/{path to file}?since={hash}&until={hash}
What I would like to do is something like this:
rest/api/latest/projects/{project}/diff/{path to file}?since=HEAD^^&until=HEAD
To resemble:
git diff HEAD^^ HEAD {my_file} (So diff between the HEAD and previous commits on that file.)
The only way I have been able to get a list of historical commits from the API is using the following from their docs:
https://stash.atlassian.com/rest/api/1.0/projects/JIRA/repos/jira/commits
which will: "the latest commits to the jira repository in the JIRA project" but not for a specific file.
From what I have been able to find it seems as though the API does not support this functionality.
I have been able to solve this, thanks to my Firfox console. The UI makes use of a history drop down showing the last 25 commits to the file with the following URL:
rest/api/latest/projects/{project}/commits?path={path_to_file}&until=refs%2Fheads%2Fmaster&start=0&limit=25
I'm trying to view the documentation of a repository at a specific point in time. Is the github pages url hackable enough that I can specific a specific commit hash?
I can't seem to find any information on the web about this.
Once you push your gh-pages branch, old files are replaced by new ones on the static files server. Only one Jekyll build snapshot allowed.
No, you can't. GitHub pages only serves the current content of the gh-pages branch.
You can, however, clone the repo and check out the commit you are looking for locally. You might have to run Jekyll locallly, though, since ts possible to not have the actual HTML files in the gh-pages branch, but a corrrectly set up jekyll page which will get converted by GitHub on-the-fly.
It's not possible via the url but you can always clone the repo and generate the doc yourself at the commit you want.
I am also unable to find an ideal solution. What I do at the moment is to have subdirectories under the branch gh-pages named for example, v1,v2 etc. Then they are accessible as
org.github.io/repo/v1/
org.github.io/repo/v2/
...
This works, but there is almost 100% duplication of content with every version upgrade.
I'd like to manage the GitHub wiki for my project at the same time as I'm developing the code. For example:
Branches
master (stable versions)
develop (development of next version)
Others... (Possible other dev / feature branches)
Ideally, I'd like the wiki to be contained in a subfolder (e.g. /wiki) of the project. Then when I'm making changes to the code I can also update the wiki as the same time (code + documentation change). It'd also mean that all my development code and documentation would be self-contained in the "develop" branch until I merge with the "master" branch. Hopefully, even if via a manual process, the GitHub wiki would then be updated after the merge with master to reflect the changes.
I've taken a look at Git's submodule feature, but from what I understand that usually points at a single revision. I'd like to somehow follow my code development so branching and merging would work as normal.
As explained in "True nature of submodules", you can make modifications and updates within a submodule, as long as you commit also the parent repo in order to record the new state of your "wiki" sub-repo.
If you intend to use Gollum to display and work on your GitHub wiki while it's on your local machine (you probably should), then you will have a trouble if you use submodules.
Gollum wants to do local commits to your local Git repository (but not pushes), but in a submodule .git is actually a file containing the local repository, not a true Git repository. This causes Gollum to break.
Submodules also have the problems that the versions aren't coupled to the parent repository, and they aren't completely de-coupled. It a nuisance to have the source code repository to want to push the new wiki version number (but not the wiki contents) every time you make a documentation change.
The solution I use is simply to clone the wiki repository into a directory inside the main project directory and add it to .gitignore. By using a consistent name for the directory across projects (e.g. github-wiki), the chance is minimized that the wiki won't be in .gitignore and gets accidentally uploaded into the main repository.
For consistency, his approach also works well for GitHub pages, although it's unnecessary as they don't experience the problem with Gollum.