@tonycrook, thanks for asking! Most users who contact the Support Team use one of the methods I mentioned: Releases or Git LFS. I haven't spoken to anyone specifically about keeping large files in Google Cloud or AWS, but feel free to contact Support if you'd like to ask specific questions about that option!
... View more
A Git repository contains every version of every file, which works really well for small text files like code. However, adding multiple revisions of large files like audio samples, videos, and datasets can increase the clone and fetch times for every user of a repository. To keep GitHub fast for everyone, we do not allow files larger than 100 MB to be tracked in repositories.
We also recommend that you keep your entire repository under 1GB to prevent excessive load on our servers. This limit is usually easy to stay within if large files are kept out of the repository. For more information about both limits, see "What is my disk quota?"
Does your project involve files or repositories above these limits? Let's explore your options for working on GitHub!
If you try to push a file larger than 100 MB to GitHub, you'll see an error message like one of these:
remote: error: File peanut/butter/jelly.so is 118.99 MB; this exceeds GitHub's file size limit of 100.00 MB
The push operation includes a file which exceeds GitHub's file size restriction of 100MB. Please remove the file from history and try again.
First, ask yourself if you really need the large file on GitHub. If not, you can remove the file from your repository's history. For instructions, see "Removing sensitive data from a repository." You can also use a .gitignore file to prevent similar files from being added in the future. For more information, see "Ignoring files."
If you do need the large file on GitHub, ask yourself why. If you're trying to distribute a large binary file, such as an installer, you can use Releases instead. Releases are GitHub's way of packaging and providing software to your users. For more information, see "About Releases."
If you need to version the large file, you can use Git Large File Storage (Git LFS). Git LFS is an open source extension to Git that allows you to work with large files, up to 2GB each, the same way as other text files. These files do not count towards the 1GB repository limit. For more information, see "Versioning large files."
If the large file is already commited to your repository, you can use git-lfs-migrate. This tool will add the large file to LFS and remove the file from the regular Git repository's history. You'll only be able to push to GitHub after both tasks are complete.
After any files over 100MB are removed or moved to Releases or Git LFS, your repository will probably be under our recommended limit of 1GB. However, some repositories, especially those with extensive histories, may be larger.
It's okay if your repository is slightly larger than 1GB, but we don't allow pushes over 2GB. If you try to push a repository larger than 2GB to GitHub, you'll see a message like this:
remote: fatal: pack exceeds maximum allowed size
fatal: The remote end hung up unexpectedly
If you've already removed any large files, you can use this command to push your repository in chunks smaller than 2GB:
git push <remotename> <commit SHA>:<branch>
However, some projects, especially those over 5GB, are just too large for GitHub. If your repository causes excessive load on our servers, you'll receive a polite email from GitHub Support requesting that you reduce the size of the repository. You can use git sizer to compute various size metrics for a Git repository, flagging those that might cause problems.
Please, contact the Support Team if you have any questions about large files and repositories. We'll be happy to help!
... View more
Project boards on GitHub are Kanban boards made up of issues, pull requests, and notes that are categorized as cards in columns of your choosing. Project boards help you organize and prioritize your work. This is what a project board looks like:
For more information, see "About project boards."
Project boards are typically used by teams to coordinate work on a specific project. I've also had great success using a project board for my personal to-do list, including tasks from multiple projects. Read on to learn how to use project boards in both ways.
Using project boards with your team
You can create project boards to coordinate with your team on specific feature work, comprehensive roadmaps, or even release checklists.
First, decide if you need a repository project board or an organization-wide project board. Is the work you're coordinating limited to a single repository, such as building a specific feature? Or, do you want to include issues and pull requests from multiple repositories in your organization to create a comprehensive roadmap, for example?
Now, you can create your project board. If your project has a similar workflow to a past project, you might want to copy an existing project board. For more information, see "Copying a project board." Otherwise, you can start from scratch. You'll be able to build the project board entirely by yourself or choose from our templates. See "Creating a project board" for instructions.
Once you've created your project board, consider enabling automation. Automation eliminates some of the manual tasks in managing a project board by automatically performing actions when certain triggering events occur. For example, after you enable automation, when you close an issue that's in your project board, that issue will automatically move to the Done column. For more information, see "About automation for project boards."
Automation only moves cards between columns in your project board. To automate adding issues and pull requests to your project board in the first place, use query parameters. Add the ?projects= parameter to the URL for opening a new issue, like this:
If you want to report a bug, please [open an issue](https://github.com/lecoursen/test/issues/new?projects=lecoursen/test/1).
You can put that URL in your README or CONTRIBUTING files or your default issue template, so people who are about to open an issue will use the correct URL. For more information, see "About automation for issues and pull requests with query parameters" and "Manually creating a single issue template for your repository."
Using a project board for your personal to-do list
I found using project boards so helpful for managing tasks with my coworkers that I started using one for my personal to-do list as well. In addition to providing email support to GitHub users, I also maintain the internal documentation for my team and write articles like this for the Community Forum. To manage all the tasks I'm responsible for across these projects, I created a project board in a private repository owned by my personal GitHub account ( lecoursen/career ).
Repository project boards can only contain issues and pull requests from that specific repository, so I can't add issues or pull requests from the GitHub repositories I work in to my project board directly. Luckily, you can add notes to a project board, and when that note contains the URL for an issue or pull request, you'll see a preview in a summary card, no matter which repository the issue or pull request belongs to:
For more information, see "Adding notes to a project board."
Every time I take on a new task at work, I add a card to one of my three to-do columns, one for each type of work I do: Support, Docs, and Community. Usually these cards reference an issue I've been assigned to (like the one above) or a pull request I've been requested to review. Sometimes, the card contains only a note reminding me to do something like watch the recording of a meeting I missed. I'm usually alerted to these tasks by Octobox, which I use to manage my GitHub web notifications. I can also check https://github.com/pulls and https://github.com/issues (which list all the pull requests and issues you've created, been assigned to, been mentioned in, or been requested to review) to see if I've missed anything.
The last thing I do each Friday is plan for the next work week by moving cards from these to-do columns to one of my doing columns: This Week. My other doing column is called Waiting... It's for anything that is in progress but not currently actionable by me. Usually this means pull requests that I've requested my colleagues review! Once they submit their reviews, I move the card back to This Week to remind myself to address their feedback.
When I finish a task, I move it to this year's done column. Right now, that column is called 2019 Review Cycle. In January, it will be easy to write the self assessment portion of my performance evaluation with the help of this list of tasks I completed in the past year! After that, I'll create a new done column, 2020 Review Cycle. The best system for you will depend on your own situation.
Finally, I have an Icebox column for things I started but have put on hold indefinitely... just in case I ever want to pick them back up. (It's hidden all the way to the right. 😆)
If you have any questions about my to-do list project board, please leave a comment below. If you need help using project boards generally, contact the Support Team! We'll be happy to help.
... View more
People often ask the Support Team if one GitHub account can own two repositories in the same network. (A network consists of a root repository, its forks, forks of its forks, and so on.) Sometimes, people want to fork the same repository to their user account twice, so they can maintain two diverging projects. Other times, they want to fork an organization's repository to that same organization.
It's not currently possible for one account to own multiple repositories in the same network, but here are some alternative workflows that will accomplish the same goals.
Using GitHub Flow
We recommend using GitHub Flow in most situations. GitHub Flow involves each contributor adding commits to topic branches and then using pull requests to merge those changes into the default branch, usually master . In many ways, each branch is like a fork owned by the same account! For more information, see "Understanding the GitHub Flow."
This approach does involve giving contributors Write permissions to your repository. If you're concerned about contributors making irrevocable changes to important branches like master , you can protect those branches. For more information, see "About protected branches."
Forking into a different account
If you'd rather use two separate repositories, another option is to create a fork in a different user or organization account. This is a great approach when you want someone to contribute to your project without having Write permissions to the original repository. That person can fork the repository to their user account, add commits to their fork, and then open a pull request to merge their changes upstream. For more information, see "Creating a pull request from a fork."
Just remember that private forks have special rules. Private forks inherit the permissions structure of the parent repository and will be automatically deleted if the owner loses access to the parent repository. For more information, see "About forks" and " Deleting a repository."
Duplicating the repository
If the new repository absolutely must be owned by the same account, you can duplicate the repository. This creates a new repository that starts out identical to the original repository but is not a fork. For more information, see "Duplicating a repository."
Because the new repository is not a fork, you won't be able to create pull requests between the two repositories. However, you can still push and pull changes between the two repositories by adding the original repository as remote for the new repository. For more information, see "Adding a remote."
Have questions about any of these options? Ask the Support Team! We'd be glad to help.
... View more
Each commit on GitHub is associated with three people: its author, its committer, and its pusher.
You author a commit when you make changes to files in a repository. You commit a commit when you apply the changes to the repository's history. You push a commit when you send those changes from the local repository on your computer to the remote repository on GitHub.
Often, a commit will be authored, committed, and pushed by the same person... but not always! Continue reading to learn how these roles are different and what to do if any one of them looks wrong on GitHub.
You author a commit when you make changes to files in a repository. Usually, that means writing code! An author is identified by both a name and an email address, like Laura Coursen <firstname.lastname@example.org> .
If you're working locally, you can tell Git who authored a set of changes by using the --author flag with git commit . If multiple people contributed to a set of changes, you can add one or more Co-authored-by trailers to the commit's message to give them all credit. For more information, see "Creating a commit with multiple authors." If you don't specify any authors, the user.name and user.email from your local Git configuration will be used by default.
If you're working on GitHub and haven't enabled Keep my email address private, we'll use the name in your profile settings and your primary email address as author information by default, but you can choose to use any other verified email address in your GitHub account each time you make a change. If you do have Keep my email address private enabled, the private email address provided by GitHub will be used instead. For more information, see "Setting your commit email address on GitHub."
Whether you work locally or on GitHub, we use the email address(es) from this author information to associate GitHub accounts with commits in most places on our site, including contributions graphs and the commits list:
If you see a different person than you expected in either one of these places, check the author information for the commit. Locally, you can use git show <SHA>:
lecoursen$ git show 9b8a3a03b6de3581a86d55d4fbf586cbf3d7218c
Author: Laura Coursen <email@example.com>
On GitHub, you can add .patch to the end of the commit URL:
From 9b8a3a03b6de3581a86d55d4fbf586cbf3d7218c Mon Sep 17 00:00:00 2001
From: Laura Coursen <firstname.lastname@example.org>
Note: This means that the email address used to author a commit can be seen by anyone with access to a repository, which is everyone on the internet for public repositories! If you don't want your personal email address in your commits, you can use the private email address provided by GitHub instead. For more information, see "About commit email addresses."
For steps to fix this commit and prevent future commits from being misattributed, see "Why are my commits linked to the wrong user?"
After you make changes to files, you need to apply those changes to the repository's history. The committer is the person who most recently applied a set of changes. You're probably familiar with applying changes by creating a commit, using git commit while working locally. In this case, the author and the committer are usually the same person.
Commits are not always committed by the author, though! When you work on GitHub.com, you're the author, but GitHub ( GitHub <email@example.com> ) is the committer. You make the changes, and we apply them for you behind the scenes. To see this yourself, use git show --pretty=fuller <SHA> to see the author and committer information for a commit you made on GitHub:
lecoursen$ git show --pretty=fuller 9b8a3a03b6de3581a86d55d4fbf586cbf3d7218c
commit 9b8a3a03b6de3581a86d55d4fbf586cbf3d7218c (origin/master, origin/gh-pages, origin/HEAD)
Author: Laura Coursen <firstname.lastname@example.org>
AuthorDate: Fri Feb 9 10:10:17 2018 -0600
Commit: GitHub <email@example.com>
CommitDate: Fri Feb 9 10:10:17 2018 -0600
On GitHub, you'll see the author(s) and committer in the commits list, if they're different:
The committer is especially important when using a GPG key to sign commits. When you add your GPG key to your GitHub account, signed commits will be verified so other people can trust that the changes really were applied by you, but only if the committer email address matches your GPG key and a verified email address on your GitHub account. For more information, see "Signing commits using GPG."
GitHub will automatically sign commits you make on GitHub.com using our own key. For more information, see "About GPG."
After making and applying changes locally, it's time to push those changes to GitHub. We determine the pusher of a commit by the credentials (username + password or SSH key) used to authenticate for the push. You must have at least Write permissions to push changes to a repository, but the changes you push could be authored or committed by anyone, regardless of their permissions. They don't even need to have a GitHub account!
There are many reasons to push changes you didn't author. Suppose you needed to remove sensitive data from your repository. This process requires rewriting your repository's history and force pushing sanitized commits to GitHub. Unless it's a solo project, this usually means pushing commits you didn't author.
So, don't worry if you see commits authored by someone who doesn't have Write permissions to your repository. They were definitely pushed by someone who does! (Again, see "Why are my commits linked to the wrong user?" for help figuring out why the author information is unexpected.)
On GitHub, you'll see the pusher of a commit in some notification emails and your news feed:
If the pusher you see is unexpected, check the credentials being used to authenticate for the push. First, use git remote -v to check if you're pushing over HTTPS or SSH. If you see HTTPS URLs like https://github.com/lecoursen/test.git , the other person's username and password is probably cached on your machine. If you're using OSX, see "Updating credentials from the OSX Keychain" for information about how to update or delete credentials in OSX Keychain. If you're using Windows, run this command to disable the credential helper:
git config --global --unset credential.helper
Then, follow the steps in "Caching your GitHub password in Git" to reset credential caching with the correct username and password.
If you see SSH URLs like git@github:lecoursen/test.git , follow the steps in "Testing your SSH connection" to check which GitHub account your SSH key is associated with.
If you're still confused about the author, committer, or pusher of a commit on GitHub, contact the Support Team! We'll be happy to help.
... View more
GitHub recommends using only one user account to manage both personal and professional repositories. Organizations make it easy to contribute to projects for work, open source, and yourself, all from the same account. There's no need to switch accounts in your browser or manage multiple credentials on the command line! If you currently have separate accounts for work and personal use, learn how to merge the accounts. Then, continue reading to learn how to make the most of this arrangement. Publicizing or hiding organization memberships If you only use one account for all your projects, that account could be a member of multiple organizations. If you don't want your coworkers to know about your open source affiliations (or vice versa), they don't have to. Learn how to publicize or hide your organization membership. Setting your author information per repository You might want to use different author information for your personal and professional projects. For example, you could use your work email address for professional repositories and your personal email address for other repositories. Learn how to change this author information for each individual repository in "Setting your email address for a single repository." Routing notifications Notifications provide updates about the activities and conversations you're interested in. If you want notifications about work repositories to go to a different email address than notifications about your own repositories, you can choose the delivery method for each organization you belong to. Leaving a job If you use one account for all your GitHub activity, you'll probably want to continue using that account even after leaving a specific job. To keep your account secure and your contributions intact, follow the steps in "Best practices for leaving your company." Private contributions you made while you were a member of an organization can remain in your contributions graph after you leave... but only if you've opened an issue or pull request in the repository. This is due to our contribution requirements. You might want to check this before leaving, if you can! Need help? Having trouble using one account for all your projects? Let the Support Team know. We'll be happy to help!
... View more
Pull requests let you suggest that changes from one branch be merged into another branch. For example, if you forked a repository and made changes to your fork's bug-fix branch, you could open a pull request to suggest that those changes be merged into the upstream repository's master branch. Pull requests also let you discuss these changes with project maintainers and other contributors. For more information, see "About pull requests."
Let's explore how to create, review, merge, and manage pull requests easily and effectively.
Creating pull requests
The first step to using pull requests is to create one! You can learn how in "Creating a pull request." Here are some ideas for enhancing the process.
Pull request templates let you customize and standardize the information you'd like to be included when contributors create pull requests. When you add a pull request template to your repository, project contributors will automatically see the template's contents in the pull request body. For more information, see "Creating a pull request template for your repository."
You can use these templates in many ways. One idea is to include a list of tasks you'd like authors to complete before merging their pull requests:
For more information, see "About task lists."
You might also request that contributors include an issue reference in their pull request body, so that merging the pull request will automatically close the issue. For more information, see "Closing issues using keywords."
You can use multiple pull request templates to address different needs. For example, you might request different information if changes are suggested for your master branch than if changes are suggested for your gh-pages branch.
To use multiple templates, you'll need to add the template query parameter to the URL for a new pull request. We suggest including these URLs in your CONTRIBUTING.md or README.md files. You can add more query parameters to these URLs to automatically add a title, labels, or assignees to the pull request or add the pull request to a project board or milestone. For more information see "About automation for issues and pull requests with query parameters."
Allowing maintainers to edit your branch
Creating your pull request from a fork? We suggest allowing edits from maintainers. Then, anyone with Write access to the upstream repository will be able to add commits to your branch. This can make the review process easier for maintainers; sometimes it's quicker for a maintainer to make a small change themselves instead of asking you to make the change.
Learn how to use this feature in "Allowing changes to a pull request branch created from a fork."
Reviewing pull requests
After you create a pull request, it's time for others to review your changes! Pull request reviews allow collaborators to comment on the changes in a pull request and either approve those changes or request further changes be made before the pull request is merged. For more information, see "About pull request reviews."
Requesting a review
Anyone with read access to a repository can leave a review. If you want a specific person or team to approve your pull request, you can request a review. This is the best way to make sure the right people see your changes! Learn how in "Requesting a pull request review."
If a reviewer requests changes to your pull request, you'll probably want that same reviewer to leave another review after you've addressed their concerns. Just request another review from that reviewer, following the same steps you used to request the first review. Many people don't realize this is an option, but it will save the reviewer from periodically checking on your progress themselves!
Using code owners
If you're a repository maintainer, you might want a specific person or team to approve any changes to a certain part of the code. For example, you might want a technical writer on your team to review any changes to the /docs directory. You can add a CODEOWNERS file to your repository to define code owners for specific files or directories. Code owners are automatically requested to review every pull request that modifies code they own. You can even have different CODEOWNERS files in different branches if, for example, the people who should review changes to the master branch are different than the people who should review changes to the gh-pages branch.
Learn how to use CODEOWNERS files in "About codeowners."
Merging pull requests
When all reviews are complete, it's time to merge your pull request! 🎉 This will apply your changes to the destination branch. Here are a few things to consider when merging pull requests.
Using protected branches
If you're a repository maintainer, you can use protected branches to prevent pull requests from being merged into important branches, such as master, until certain conditions are met. For example, you can require passing CI tests or an approving review. For more information, see "About protected branches."
Using different merge methods
When you merge a pull request, you'll see a few merge methods to choose from:
Different merge methods work for different projects. If you're a repository maintainer, you can force contributors to use your preferred merge method by disabling the others. For more information, see "About pull request merge methods."
Managing your pull requests
You're probably involved in quite a few pull requests, in multiple repositories, at any given time. We suggest using http://github.com/pulls to keep track of all these pull requests. This page lists all the pull requests that you created, are assigned to, were mentioned in, and were requested to review across all of GitHub:
Looking for further learning?
There's a GitHub Learning Lab course for that! If you'd like to learn more about reviewing pull requests, you can check out our Reviewing Pull Requests course. This course dives into how you can get your best work done by identifying when and how to request a review, how to perform a review for someone else's pull request, and other awesome collaboration methods.
We hope these tips make it easier for you to create, review, merge, and manage pull requests. If you have any questions, let the Support Team know! We're always happy to help.
... View more
GitHub is most powerful when you use it to collaborate with others. We'll send you notifications to make this collaboration easier, keeping you updated on activities and conversations that involve or interest you.
Here are some tips for making your notifications as helpful as possible.
Understanding the available types and delivery methods of notifications can help you optimize your notifications preferences.
Types of notifications
There are two main types of notifications: participating and watching.
Participating notifications are for events that directly involve you. We'll send these notifications if you or a team you're in has been mentioned in a comment, assigned to an issue, or requested to review a pull request, for example.
If you'd like to be updated about events that don't directly involve you, you can watch a repository or team discussion. You'll receive watching notifications for every issue, pull request, and release created in these repositories and every post in these team discussions. You can check which repositories you're watching here.
These are just a few examples of participating and watching notifications we'll send. See the full list.
You can choose to receive both participating and watching notifications on GitHub.com, via email, or both.
These notifications have a shared read state. If you enable both web and email notifications, opening an email notification will mark the web notification as read. If this shared read state doesn't work for you, learn how to prevent your web notifications from being marked as read.
Getting started with notifications
Now that you understand how notifications work, it's time to choose your preferences.
First, follow this guide to choose your delivery methods—if any!—for participating and watching notifications.
If you enable email notifications, you'll have a few more choices to make. Scroll down to Email notification preferences.
Choose a default notifications email address. Note that your default notifications email address is not the same as your primary email address, which receives GitHub system messages (such as repository transfer notifications).
Then, choose whether you want to receive notifications for each of the following events:
* Comments on issues and pull requests * Pull request reviews * Pull request pushes
Finally, decide whether you want to receive notifications for your own actions. This can be helpful if you'd like your email inbox to include the full history of an issue or pull request, including your own comments.
Notifications level: expert
Now that you've chosen your basic preferences, you can make notifications even more powerful by taking advantage of these additional features:
Disable automatic watching
You may be automatically receiving notifications for all repositories you have push access to. If you have access to a large number of repositories, this might be too noisy. Follow this guide to disable automatic watching.
If you're a member of any organizations, you can receive notifications at different verified email addresses depending on the organization that owns the repository. Learn how to enable this custom routing.
Note: This feature is only available for organization members. If you don't see a custom routing option in your settings, you might be an outside collaborator instead.
Email service hooks
You can get email or web notifications when new commits are pushed to a pull request you're subscribed to. If you'd like to be notified of every push to a repository, you can set up an email service hook.
Each email notification includes headers that provide information about the notification and why you're receiving it. Learn how to see email headers in Gmail.
You can use these headers to set up Gmail filters based on the repository the notification is about or the reason you're receiving the notification. Here's an example:
Matches: from:(firstname.lastname@example.org) to:(-email@example.com -firstname.lastname@example.org -email@example.com)
Do this: Skip Inbox, Apply label "Notifications"
Matches: from:(firstname.lastname@example.org) to:(email@example.com)
Do this: Skip Inbox, Apply label "Notifications/Mentioned"
Matches: from:(firstname.lastname@example.org) to:(email@example.com)
Do this: Skip Inbox, Apply label "Notifications/Team"
Matches: from:(firstname.lastname@example.org) to:(email@example.com)
Do this: Skip Inbox, Apply label "Notifications/Author"
With these filters, all email notifications from GitHub will skip your inbox. Labels will also be applied to each email that indicate why you received the notification: you were mentioned, a team you're a member of was mentioned, or you created the issue or pull request.
Note: Sometimes you will be subscribed to an issue or pull request for one reason (for example, you commented on an issue) and that reason will later change (for example, you are directly mentioned in a later comment on that same issue). This will change the notification reason if the new reason is considered more important than the original reason. For eample, mention overrides comment, so the cc address for email notifications about that issue will be firstname.lastname@example.org going forward.
Other headers can help you troubleshoot when you receive notification emails you weren't expecting. Usually, this happens when a different email address is set up to forward notifications to you. You can check the X-GitHub-Recipient and X-GitHub-Recipient-Address headers to see which account the notification was intended for.
See the full list of email headers for email notifications.
If you want the granular control of filtering but prefer web notifications, consider using Octobox. It's an open-source project that adds filters and an extra "archived" state to web notifications:
Octobox adds an extra "archived" state to each notification so you can mark it as "done". If new activity happens on the thread/issue/pr, the next time you sync the app the relevant item will be unarchived and moved back into your inbox.
Quite a few members of the Support Team use it, including me!
We want notifications to make collaboration on GitHub easier for you. If you're having any trouble with your notifications, let the Support Team know. We'll be happy to help!
... View more
The GitHub support team knows that your contributions graph matters. In fact, we have received 1,276 emails about contributions in the past six months alone! We know that it can be frustrating to realize that hours of hard work are missing from your graph and that it can be difficult to determine why. We'll only add contributions to your graph if they meet certain criteria. Here are a few questions to ask yourself to ensure that your commits do meet those criteria so your graph accurately reflects all of your work. Did you set your email address in Git? Your commits only count as contributions if you author those commits using an email address that is associated with your GitHub account. That author information usually comes from your local Git configuration, so make sure you've followed these steps to set your email address correctly. Note: You might have to enter your email address on the command line when you push a commit, but this isn't what gets the commit in your contribution graph. Make sure to also add your email to your local Git configuration. If your graph is already missing commits for this reason, don't worry! You can fix it. First, check to see which address you used to author the commit by adding .patch to the end of the commit URL, like this: https://github.com/octocat/octocat.github.io/commit/67c0afc1da354d8571f51b6f0af8f2794117fd10.patch Then, check your email settings to see if the address you found is associated with your GitHub account. If not, follow these steps to add the address. It's okay if you can't verify the address—just adding the address will do! If the address is generic (like email@example.com) or already associated with another GitHub account, you won't be able to add that address to your account. If that's the case, you will need to rewrite the entire history of your Git repository for the commit to be counted as a contribution. Rewriting history is considered bad practice if you're collaborating with others, so we recommend doing so only in an emergency. If you do decide to go forward, here are a few instructions. Are you working in a fork? Commits to forks do not count as contributions until those commits have been merged into the upstream repository. If you don't plan to ever merge your changes upstream, you should consider working in a standalone repository instead. You can still use someone else's project as a starting point for your own project if the repository's license allows for it: 1. Clone the repository you want to use. 2. Create a new repository on GitHub. 3. Change the local repository's remote URL to point to your new repository. 4. Push the local repository to your new repository on GitHub. Already started working in a fork? Support can detach your fork for you! Learn more. Are you starring repositories you contribute to? A commit will only count as a contribution if one of the following is true: You are a collaborator on the repository or are a member of the organization that owns the repository. You have forked the repository. You have opened a pull request or issue in the repository. You have starred the repository. We recommend starring any repositories you contribute to. That way, your commits to those repositories will remain in your contributions graph even if you leave the organization that owns the repository or delete your fork of the repository. Learn more about stars. Did you choose to show private contributions? GitHub hides commits in private repositories from your contributions graph by default. Learn how to display this activity to fill in your graph with as many green squares as possible. How long has it been since you pushed the commit? The contributions data for each repository is recalculated every time someone pushes to that repository. This can take some time, so if you made a commit recently, you may need to wait a few hours before the contribution shows up in your graph. Ask us! If you've asked yourself all these questions, and you're still missing contributions, there may be something wrong on our end! Want to make sure a specific commit to a public repository meets all the criteria for making your graph? Try this app. If a commit that does meet all these criteria is still not in your graph after 24 hours, let the support team know! Contact us with the URL for the commit. We'll be happy to investigate!
... View more