GitHub Procedures: Difference between revisions
Line 195: | Line 195: | ||
** Create | ** Create | ||
* Settings → Notifications → Address: space separate list → Use the OD group address. Setup notifications. | * Settings → Notifications → Address: space separate list → Use the OD group address. Setup notifications. | ||
* Settings → Collaborators & teams → Add a team with "Write" permissions. |
Revision as of 18:03, 11 May 2022
Internal
gh CLI
Making a Public Release
Overview
This is the procedure to make a "public release" for a GitHub-hosted project. This type of releases are accessible via the GitHub project page -> "releases" tab. The release procedure assumes that the release tag was already applied to the repository, either manually or via nort. At the time of the writing, nort is being extended to automate this procedure.
Procedure
GitHub Project Home -> "releases" tab -> "Draft a new release"
Copy and paste the release tag from the local release procedure output or from git tag output. The format is similar to "[project-name-]release-4.2.2".
Upon pasting it into the release input box, the site should recognize it as "Existing tag".
Release title: 4.2.2
Describe the release:
Specify Introduced features and defect fixes. This will be part of the release history. Projects maintain notes to be consolidated into the release announcement in ./doc/release-notes.md. Copy and edit the content from there.
Attached files:
- If is an installable release, attach binaries: "Attach binaries by dropping them or selecting them."
- If it is a library release, don't attach anything, as the libraries can be recreated from the tagged source tree, and in the future, we'll publish to a public Maven repository.
"Publish release"
Clean ./doc/release-notes.md and commit.
cat /dev/null > ./doc/release-notes.md git add ./doc/release-notes.md git commit -m "cleaned ./doc/release-notes.md post-release" git push
Link to a Specific Line
Use #L<start>-L<end>
https://github.com/moby/moby/blob/master/oci/defaults.go#L14-L30
Issue Queries
is:issue is:open author:ovidiuf
Authentication
Create a Personal Access Token for Command Line
This procedure describes creation of personal access tokens:
Profile-photo icon -> Drop Down -> Settings -> Developer settings -> Personal Access Tokens -> Generate a new token.
Token description:
OAuth scopes: To use your token to access repositories from the command line, select repo.
Make sure to copy your new personal access token now. You won’t be able to see it again!
Scopes:
Other PAT Operations:
GitHub Authentication for AWS CodePipeline
Pull Request Procedures
Search Pull Requests
Open Pull Requests
is:pr is:open
Based on the Branch They Are Merging Into
base: BASE_BRANCH
By Author
author: USERNAME
Merge an Approved Pull Request
There are three options:
- Create a merge commit: all commits from the head branch will be added to the base branch with a merge commit. The commits on the head branch are preserved in the repository. The merge is performed using the --no-ff option.
- Squash and merge: if the head branch contains multiple commits, they are squashed into single one. Then the resulting commit is merged into the base branch using the fast forward option. What if in the mean time, new work also occurred on the base branch? Most likely, a merge commit will be created. Verify that. This option might be useful if you try create a more streamlined Git history in your repository. Work-in-progress commits are helpful when working on a feature branch, but they aren’t necessarily important to retain in the Git history. If you squash these commits into one commit while merging to the default branch, you can retain the original changes with a clear Git history. Of course, squashing can be done prior to the pull request, based on logical considerations and commit boundaries.
- Rebase and merge - all commits from the head branch are added on the base branch individually without a merge commit.
Insert a Suggestion within a Pull Request
Click on the Blue + → "Insert a Suggestion" icon:
Change the Base Branch of a Pull Request
Make a Pull Request from a Forked Repository
Fork
Fork the repository with the GitHub "Fork" functionality.
Clone Locally
Clone the fork locally
Track the Original Repository as a Remote of the Fork
Once a repository is forked, changes to the upstream repository are not pushed to the fork. The newly forked repository can be configured to follow changes on the upstream, via a remote.
Existing remotes can be listed with:
git remote -v
Adding the upstream repository as a remote:
git remote add --track master upstream git@github.com:my-upstream-org/my-upstream-repo.git
git fetch upstream
The new remote will become visible, as "upstream", with git remote -v
.
Create a Branch with Changes
git branch some-branch
git checkout some-branch
Make the Changes, Add, Commit and Push Changes
Make the changes locally then:
git add .
git commit -m "some changes"
If it is the first time you push, set the upstream branch as part of the push command:
git push --set-upstream origin my-branch
Note that the change is pushed in the origin repository, not the upstream repository.
Once the change is pushed in the forked repository, it will show up in the UI of the forked repository ("some-branch had recent pushes 1 minute ago") but also in the UI of the upstream repository ("ovidiu-feodorov:some-branch had recent pushes 1 minute ago").
Submit a Pull Request to the Upstream Repository
From the UI of the original (upstream) repository, go to the Pull Request tab. You should find your change there. Use "Compare & pull request" → "Create pull request".
Post-PR
After the PR is accepted, sync the forked repo with the upstream - you should see the change there. From the forked repository:
git fetch upstream
git checkout <target-branch>
git merge upstream/<target-branch>
git push
- Remove the local branch.
git branch -d my-branch
git push origin :my-branch
Doesn't this leave redundant commits around?
Create a Repository
- Immediately after creating the repository with the UI, clone it locally.
- Create and push the "develop" branch.
git checkout -b develop # local change git commit -m "'develop' init" git push --set-upstream origin develop
- Settings → Options → Merge button → Enable "Automatically delete head branches"
- Settings → Branches → Default branch → Switch default branch to another branch (⇄ icon) → "develop"
- Settings → Branches → Branch protection rules → Add Rule. For branch name pattern: "main", "develop"
- Require pull request reviews before merging: Required approving reviewers 2, Dismiss stale pull request approvals when new commits are pushed.
- Create
- Settings → Notifications → Address: space separate list → Use the OD group address. Setup notifications.
- Settings → Collaborators & teams → Add a team with "Write" permissions.