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".
Related
(For reference, here is a command line git solution How to handle review a pull-request, modify code, and merge?)
Here I'm looking for a 100% in-browser solution directly in the Github interface.
I have a repo foobar
I receive a pull request from user bob
I would like to make a few tiny edits on his modifications, and merge this PR
How to do this 100% from the Github interface, without having to open a command-line and do git ... operations?
Note: I don't want to merge bob's as it is, and do modifications later in a further commit. I would like to edit his PR before merging it to my project.
First go in the Files changed tab of the pull request. There you could edit the files with the Edit file button.
That works if you have write access to the repo and the pull request author enables Allow edits by maintainers. (Enabled by default)
The checkbox could also be checked or unchecked after creating the pull request.
I am a noob to github's organziation settings and all. Don't know if we need these settings for the question Im about to ask.
So what I want to achieve is to show the already opened pull request's link on a subsequent push. In the past when working with bitbucket and gitlab with a development team, the link used to appear both on the initial push to create a pull request and also on subsequent commits push to PR. But in my current workflow it only appears on initial push to create the PR. (Note I haven't been setting up repositories in the past myself and just starting to explore this area so no idea if in the past lead engineer has been adding any settings or not)
This is what I see on initial push:
And this is on subsequent push. No link to already opened pull request
What am I missing? And is it even possible to do?
Any read or keywords to search for would be appreciated.
First a remark : when running git push, lines prefixed with remote: are actually generated by something on the remote ("something" = a script or a program or ...). If you want to see something more, check if there is some setting on Github's side to re-display the merge request number when you update a branch (I must confess I don't know if and how this can be done).
If you want to find what pull request is linked to a known branch, there is a specific search filter (in the web GUI) for that : head:branch_name
As an example :
Here is how you could get PR #1037 (linked to a branch named leaksan-100-part2) on git's repository :
is:pr head:leaksan-100-part2
If you want to get this from a script, you should probably use Github's API :
the doc to Pulls API mentions a base attribute :
base string query Filter pulls by base branch name. Example: gh-pages.
I feel like this question must have been asked before, but I'm not finding it on here. I have a file that I want in a GitHub repo, in this case a file in which the user would paste their API keys after cloning. I want this blank file to be cloned down, but I don't want it to be tracked or pushed. I already have it listed in the .gitignore file that is contained in the repo, yet after pulling and modifying the file, git status still shows the file as being tracked and having changes that need to be committed. How can I get around this?
You could do something like this via Github Enterprise's pre-receive hooks functionality.
From the readme, you can create a pre-receive hook that:
Prevents sensitive data from being added to the repository by blocking keywords, patterns or filetypes.
On a Github project, I see a guy made a pull request in Pull Requests section, but I find he made many mistakes so his code need to be corrected. Instead of asking him to change his code, is it possible to do it by myself (that is, I want to correct his code by myself)? and how?
I'm also a member of that project, and I'm new :)
Enabling repository maintainer permissions on existing pull requests
Pull request creators can give these permissions on each of their pull requests when they initially create a pull request from a fork or after they have created the pull request.
On GitHub, navigate to the main page of the upstream repository of your pull request.
In the list of pull requests, navigate to the pull request that you'd like to allow commits on.
In the right sidebar of your pull request, select Allow edits from maintainers. You can change these permissions at any time by unselecting this option.
More details on github help page: Allowing changes to a pull request branch created from a fork
TL;DR
Author of PR can modify an existing pull request to let repository maintainers make commits to your branch.
In order to allow you to make commits to others PR - the author has to set checkbox from the left:
Assuming the original author is responsive enough, it’s always better to ask them to fix it (unless the change is an obvious typo fix, maybe). They might have a reason for writing it the way they did.
If the author isn’t responsive and you’re deciding whether to fix it in place or with a new commit, ask yourself which way the history reads more clearly. If the commit would introduce a regression, you should probably fix it in place (to avoid breaking bisectability). If it handles some cases and you just want to add more cases without significantly changing the existing code, it might be better to add a new commit.
If you do amend the existing commit in any way, make sure to leave a note in the commit message explaining what you changed. One typical style is to leave a note in square brackets, grouped with any Signed-off-by: lines (if applicable):
[your.email#example.com: Refactor new cases into a function for clarity]
For example: linux.git commit b44129b3.
via https://www.quora.com/GitHub-Is-it-bad-etiquette-to-change-someones-pull-request-before-committing
I want to fork a github project to fix a couple of issues and then send a pull request.
The problem I'm running into is that I've already forked the project to adapt it for another user base.
Is it possible to create a second fork? If so, how?
When I try to fork now it just takes me to the previously created fork.
There is no way to have two forks of the same GitHub project unless you use two different GitHub accounts.
So:
Create a separate GitHub account (and verify the email)
Fork the
project
Invite your main GitHub account as a "Collaborator" (from
the settings)
You may need to add the extra step of creating an organization with the new GitHub account and inviting your main github account as an owner of the organization (also make sure your new fork is in that new organization). This will let you do things like deploy automatically to a Heroku app that is connected to your main GitHub account.
Why can't we just have multiple forks???
I mean that I could just commit and push without making a pull request, but I want to do it the offical way and I want somebody else to review the changes before I push to a public project.
GitHub pull requests do not need to be submitted from a fork; they work within a single repository as well:
Pull requests are especially useful in the fork & pull model because they provide a way to notify project maintainers about changes in your fork. However, they're also useful in the shared repository model where they're used to initiate code review and general discussion about a set of changes before being merged into a mainline branch.
There's nothing stopping you from creating a pull request even if you don't technically have to. This is often considered a best practice, and GitHub's own Flow model is largely based on pull requests.
Creating a pull request within a single repository is very similar to creating one from a fork:
Create a feature branch and push your work to that branch on GitHub
In the GitHub web UI, switch to your feature branch
Click the "Compare" & review button
The trick is not to use the master branch to create pull requests. Then you won't need to create multiple forks since you can make as many branches as you need and make pull requests against each branch independently.
Given a clean forked repo, create a dedicated branch and use that branch for the pull request.
You can create branches from the web UI (although it is not obvious).
Click the branch selection dropdown, type the new branch name in the input field, and then you'll see a clickable link Create branch: <new-branch-name> as shown below. The tricky UI part is that it might not be very obvious you should click the "create branch: xyz..." — it is NOT displayed as a button or as a hyperlink, and there is NO indication that this is a clickable link. Moreover, there is NO hint whatsoever that a branch can be created until you type in the search box — anyone would probably assume that the search box is used exclusively for searching branches, and not for creating them.
In case you already made changes directly in your fork's master branch then consider moving those changes into a dedicated branch and hard resetting the master branch to the original remote so that you keep it clean for synching with the upstream repo.
See also:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository
The best way, recommended by github manual, is use command line git, mirror clone your repo and push it to your github.
https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/duplicating-a-repository
If you strongly prefer GitHub web interface to the command line, a GUI friendly workaround is create a new organization and fork to that new organization.
Another GUI way I can think of is to declare a fork as a template repo using repo's setting so you can create as many forks as you need.