Add content to git/github roadmap (#6605)
Stavros Siamantas
3 months ago
committed by
GitHub
parent
0d5355018b
commit
f30772d330
35 changed files with 226 additions and 32 deletions
@ -1 +1,9 @@ |
||||
# Handling Conflicts |
||||
|
||||
When multiple developers work on the same project simultaneously, conflicts can arise during the merging process. This occurs when changes made by different individuals overlap or contradict each other in a specific code file. In such situations, Git's conflict resolution mechanism comes into play, allowing users to manually resolve these issues and merge the conflicting changes. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Resolving a merge conflict using the command line](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line) |
||||
- [@article@Resolve merge conflicts in Visual Studio](https://learn.microsoft.com/en-us/visualstudio/version-control/git-resolve-conflicts?view=vs-2022) |
||||
- [@video@Resolve Git MERGE CONFLICTS: The Definitive Guide](https://www.youtube.com/watch?v=Sqsz1-o7nXk) |
||||
@ -1 +1,8 @@ |
||||
# HEAD |
||||
|
||||
The `HEAD` file is at the core of how Git knows the SHA-1 of the last commit when running commands like `git branch <branch>`. It serves as a symbolic reference, pointing to the current branch. However, in rare cases, HEAD can contain the actual SHA-1 value of a Git object, such as when checking out a tag, commit, or remote branch, which puts your repository in a "detached HEAD" state. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Git Internals - Git References - The HEAD](https://git-scm.com/book/en/v2/Git-Internals-Git-References#:~:text=want%20to%20create.-,The%20HEAD,-The%20question%20now) |
||||
- [@video@Learn Git Essentials: Head & Detached Head](https://www.youtube.com/watch?v=HvDjbAa9ZsY) |
||||
@ -1 +1,7 @@ |
||||
# History |
||||
|
||||
The history of a Git repository is a record of all commits made over time, including changes to files, commit messages, and metadata. This history is stored as a series of snapshots, with each commit representing a new version of the codebase. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Git Basics - Viewing the Commit History](https://git-scm.com/book/en/v2/Git-Basics-Viewing-the-Commit-History) |
||||
@ -1 +1,11 @@ |
||||
# Installation and Setup |
||||
|
||||
The GitHub CLI can be installed on Windows, macOS, and Linux operating systems. Installation options include downloading binaries directly from the release page or using package managers (such as homebrew, pip, etc). |
||||
|
||||
Once installed, setting up the GitHub CLI typically involves authenticating with your GitHub account by running `gh auth login` in your terminal. This step is essential for linking your GitHub credentials to the CLI, allowing you to interact with your repositories and perform various actions. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@GitHub CLI - Installation](https://github.com/cli/cli?tab=readme-ov-file#installation) |
||||
- [@official@GitHub CLI - Release](https://github.com/cli/cli/releases/) |
||||
- [@official@GitHub CLI quickstart](https://docs.github.com/en/github-cli/github-cli/quickstart) |
||||
@ -1 +1,14 @@ |
||||
# Installing Git Locally |
||||
|
||||
To use Git on your local machine, you need to install it first. The installation process varies depending on your operating system: |
||||
|
||||
- On Windows: Download the binary from the official Git or GitHub release page and follow the installation instructions. |
||||
- On macOS (using Homebrew): Run `brew install git` in your terminal. |
||||
- On Linux: Run `sudo apt-get install git` or `sudo yum install git` depending on your distribution. |
||||
|
||||
Once installed, you can verify the Git version by running `git --version` in your terminal. This will display the currently installed Git version. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Git - Downloads](https://git-scm.com/downloads) |
||||
- [@article@Install Git](https://github.com/git-guides/install-git) |
||||
@ -1 +1,14 @@ |
||||
# Issue Management |
||||
|
||||
The GitHub CLI provides a range of features for managing issues within your repository. Here are some key actions you can perform: |
||||
|
||||
- Listing issues: Run `gh issue list` to view a list of all open and closed issues. |
||||
- Creating issues: Use `gh issue create --title "Issue Title" --body "Issue body"` to create a new issue with the specified title and body. |
||||
- Assigning issues: Run `gh issue assign <issue-number> <username>` to assign an issue to a specific user. |
||||
- Labelling issues: Use `gh issue label <issue-number> <label-name>` to add a label to an existing issue. |
||||
- Closing issues: Run `gh issue close <issue-number>` to mark an issue as closed. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@gh issue](https://cli.github.com/manual/gh_issue) |
||||
- [@video@Manage GitHub Issues From The Command Line Using GitHub CLI](https://www.youtube.com/watch?v=nuCQiP41jU0) |
||||
@ -1 +1,18 @@ |
||||
# Issues |
||||
|
||||
On GitHub, an issue is a way to track and report bugs, feature requests, or other problems with a repository. Here are some key aspects of issues: |
||||
|
||||
- Creating issues: Users can create new issues by submitting a form on the repository's Issues page. |
||||
- Issue titles and descriptions: Each issue has a title and body (description), which provide context for the problem or request. |
||||
- Assignees: Issues can be assigned to specific users, who are then responsible for addressing the issue. |
||||
- Labels: Labels are used to categorize issues by topic, priority, or other criteria. This helps filter and organize issues within a repository. |
||||
- States: Issues have states that reflect their status, such as "Open", "Closed", or "Pending". |
||||
- Comments: Users can comment on existing issues to discuss or provide additional context. |
||||
- Labels and milestones: Issues can be associated with labels (topics) and milestones (deadlines), which help filter and prioritize them. |
||||
|
||||
Issues are a core feature of GitHub repositories, enabling teams to collaborate effectively on resolving problems and implementing new features. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@About Issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues) |
||||
- [@video@What is GitHub Issues?](https://www.youtube.com/watch?v=6HWw7rhwvtY) |
||||
@ -1 +1,10 @@ |
||||
# Kanban Boards |
||||
|
||||
On GitHub, Kanban boards provide a visual representation of issues as they move through the development process. |
||||
|
||||
A Kanban board typically has columns representing different stages or states, such as "To-Do", "In-Progress", and "Done". Each issue is represented by a card on the board, which can be moved between columns as its state changes. Users can drag and drop issue cards to move them from one column to another, reflecting progress or completion. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Projects - Boards - Changing the layout of a view](https://docs.github.com/en/issues/planning-and-tracking-with-projects/customizing-views-in-your-project/changing-the-layout-of-a-view) |
||||
- [@video@GitHub Project Management - Create GitHub Project Board & Automations](https://www.youtube.com/watch?v=oPQgFxHcjAw) |
||||
@ -1 +1,14 @@ |
||||
# Labelling Issues / PRs |
||||
|
||||
On GitHub, labels are a way to categorize issues and pull requests (PRs) by topic, priority, or other criteria. Some common labels used are: |
||||
|
||||
- `Bug` |
||||
- `Duplicate` |
||||
- `Enhancement` |
||||
- `Feature request` |
||||
- `High priority` |
||||
- `Needs feedback` |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Managing labels](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels) |
||||
@ -1 +1,11 @@ |
||||
# Linear vs Non-Linear |
||||
|
||||
In Git, linear and non-linear history refer to different ways of managing commit history. |
||||
|
||||
- Linear history: A repository with a linear history has commits that are applied in a single, sequential order. |
||||
- Non-linear history: A repository with a non-linear history allows multiple branches or lines of development, which can be merged back into the main branch at different points. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@article@Linear vs Non-Linear History](https://idiv-biodiversity.github.io/git-knowledge-base/linear-vs-nonlinear.html) |
||||
- [@article@Linear git history - Part I](https://jun-sheng.medium.com/linear-git-history-part-i-b97184dde252#:~:text=The%20benefit%20of%20having%20a%20linear%20git%20history&text=It%20is%20easier%20to%20understand,bisect%20to%20track%20a%20bug.) |
||||
@ -1 +1,11 @@ |
||||
# Local vs Global Config |
||||
|
||||
To manage local and global configuration settings, you can use the git config command with the --local and --global options. |
||||
|
||||
- Local configuration: Run `git config --local [key] [value]` to set a local configuration setting for the current repository. |
||||
- Global configuration: Use `git config --global [key] [value]` to set a global configuration setting that applies to all repositories on your system. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Customizing Git - Git Configuration](https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration) |
||||
- [@article@A step-by-step guide to setting up global Git config properties](https://medium.com/geekculture/a-step-by-step-guide-to-setting-up-git-config-global-properties-db6dbce30fa8) |
||||
@ -1 +1,14 @@ |
||||
# Managing Remotes |
||||
|
||||
In Git, a remote repository refers to a copy of a project's source code stored on a server or other machine. |
||||
|
||||
- Adding remotes: Use `git remote add [name] [url]` to add a new remote repository. This allows you to track changes and push/pull updates from the remote. |
||||
- Listing remotes: Run `git remote -v` to list all configured remotes with their URLs. |
||||
- Renaming remotes: Update the name of an existing remote using `git remote rename [old-name] [new-name]`. |
||||
- Deleting remotes: Remove a remote repository with `git remote remove [name]`. |
||||
|
||||
Managing remotes is essential for collaborating on projects or tracking changes from upstream sources. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Managing remote repositories](https://docs.github.com/en/get-started/getting-started-with-git/managing-remote-repositories) |
||||
@ -1 +1,14 @@ |
||||
# Managing Tags |
||||
|
||||
In Git, a tag is a named reference to a specific commit in the project's history. |
||||
|
||||
- Creating tags: Use `git tag [name] [commit-hash]` to create a new tag. You can also use `git tag -a [name] -m "[message]" [commit-hash]` for annotated tags. |
||||
- Listing tags: Run `git tag` to display all existing tags. |
||||
- Deleting tags: Remove an existing tag with `git tag -d [tag-name]`. |
||||
|
||||
Tags can be used for marking releases, milestones, or other significant events in a project's history. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Git Basics - Tagging](https://git-scm.com/book/en/v2/Git-Basics-Tagging) |
||||
- [@article@Git — Use Tags for Versioning and Release Management](https://medium.com/@KeyurRamoliya/git-use-tags-for-versioning-and-release-management-09aca9631eee) |
||||
@ -1 +1,14 @@ |
||||
# Markdown |
||||
|
||||
Markdown is a simple way to add formatting to text without using HTML tags or other complex syntax. It's easy to read and write, making it suitable for documentation, README files, and more. Some basic GitHub Markdown features include: |
||||
|
||||
- Basic syntax: Use headers (`# Heading`), bold/italic text (**bold**, *italic*), and lists (- item) to format text. |
||||
- Links: Create links with `[text](url)` or `[text][ref]`. |
||||
- Images: Embed images with `[]`. |
||||
|
||||
By using Markdown, you can easily format text within your GitHub repository, making it easier to read and understand for yourself and others. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Basic writing and formatting syntax](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax) |
||||
- [@article@Markdown Cheatsheet](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) |
||||
@ -1 +1,13 @@ |
||||
# Marketplace Actions |
||||
|
||||
The GitHub Marketplace offers a wide range of pre-built actions that can be used to automate tasks and workflows within your repository. |
||||
|
||||
- Automate tasks: Use marketplace actions to automate tasks such as testing, deployment, or security. |
||||
- Customize workflows: Create custom workflows using marketplace actions to tailor the build process to specific needs. |
||||
- Streamline development: By automating repetitive tasks, developers can focus on code quality and collaboration. |
||||
|
||||
These actions are created by the GitHub community and can be easily added to your workflow to enhance productivity and efficiency. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@GitHub MarketPlace - Actions](https://github.com/marketplace?type=actions) |
||||
@ -1 +1,3 @@ |
||||
# Mentions |
||||
|
||||
Mentions on GitHub allow you to notify specific users or teams about comments, issues, pull requests, or other activities. This feature improves collaboration by encouraging participation and discussion among team members, increasing visibility of important topics, and streamlining communication within your repository. To use mentions, simply type `@username` or `@teamname` in a comment, and GitHub will auto-complete the mention as you type, automatically linking their username to the comment and notifying them about the discussion. |
||||
@ -1 +1,9 @@ |
||||
# Merge Strategies |
||||
|
||||
When combining changes from one branch into another, Git provides various merge strategies to choose from. These methods allow for flexibility and customization in integrating code updates into your main branch. The available options include: |
||||
|
||||
- Fast Forward (FF) |
||||
- Non-Fast Forward |
||||
- Rebase |
||||
- Squash |
||||
- Cherry Picking |
||||
@ -1 +1,8 @@ |
||||
# Merging Basics |
||||
|
||||
A merge in Git is the process of combining changes from one branch into another. When you want to integrate updates from one branch (the source) into another branch (the target), you need to perform a merge. This involves resolving conflicts between the two branches, if any exist. The goal of merging is to create a new commit that represents the combined changes from both branches, resulting in a single, cohesive history for your project. |
||||
|
||||
Visit the following resources to learn more: |
||||
|
||||
- [@official@Git Branching - Basic Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#:~:text=into%20master%20later.-,Basic%20Merging,-Suppose%20you%E2%80%99ve%20decided) |
||||
- [@article@Git merge](https://www.atlassian.com/git/tutorials/using-branches/git-merge) |
||||
Loading…
Reference in new issue