Is there a way to hide a specific PR from a public GitHub repo until it is ready for review? I push code to the public repo at least at end of every day. There is a lot of work in progress in my code. Is there a way to hide commits and PR from the public repo? Or should I change my workflow and not commit the code until I'm satisfied with it.
If you push your commits or open a Pull Request on the public repository, there is no way to hide the changes. You will have to change your workflow.
Keep in mind that you are pushing the entire commit history, and it is publicly available. If you accidentally commit an API key, you must manually delete the commit from history. But that action is complex. Take a look at this question.
Related
I am trying to make a backup PR for my repo when there is new PR merged.
Is this possible to do it with GitHub actions?
Also, could it be a stand alone app/repo to manage other repos?
You would probably only create a revert PR only after the initial PR was merged, otherwise you could run into all kinds of issues.
This can definitely be implemented via GitHub Actions, by getting triggered by a PR merged trigger and checking the added commits in the initial PR and creating a revert for them back to whatever the base branch was before.
Still, GitHub is already able to do this natively with a click of a button in a PR, so I'm not sure what need this would fill.
See GitHub Docs: Reverting a pull request
Do we have any way to Gate-Keep our organisation's GitHub Commits? I want to ensure none of our developer's GitHub commits to public repository is exposing any specific strings/Keys.
So a Gatekeeper scripts which parses through the Commits made by our developers and forbids a commit in case it exposes a particular string. I am aware Private repository is the obvious solution but we should have restriction on public repository
too.
You might consider putting in place a GitHub Action workflow, similar to this repository in order to scan the content of a pushed commit (using one of the security scanners).
And, as an action, you could reset the branch to the previous commit, effectively cancelling what has just been pushed.
If the action does not detect any sensitive data, you can in turn push the commit to a protected branch, which acts as the blessed content from which developers can pull.
This question pertains to my workflow using github. My colleague sent me a pull request and kept advancing the branch he was working in with new commits? I want to pull the commits related to the pull request, but the pull request now has the commits too. I searched for solutions and kept being led to the "rebase" command. Regrettably, that command is too complicated for me, plus I use tortoiseSVN as my interface to github. I had some solutions using revert, but they were all un-elegant and there had to be something easy. Also the last time I tried a revert, I had some conflicts with commits that no longer existed because of the revert.
My colleague got a response from a github "ask a human". I am reporting the solution here to help other users.
Navigate to the branch with the work to be pulled.
Navigate to the commit history for the branch and identify the point in that history that you want to pull into the master.
Click on the button on the right marked "<>" == "Browse the repository at this point in the history".
Click on the branch pull down menu and create a new branch. This will create a new branch at that point in the history that you want to pull into the master.
Create and execute a pull request to merge that branch into the master.
Too easy. I don't understand how I didn't run across an example of this workflow. I hope I save someone else the time and headaches that I spent.
I may have screwed up, but there a way to get a code review going on GitHub after I did the below workflow?
I cloned a remote repository, branched the master and made my changes. I committed the changes, merged my branch into master, then ran a sync on GitHub and the changes are there now.
I'd now like to initiate a post-checkin review, but didn't fork the repository and so can't initiate a pull request, which as I understand it now is the common way to get reviews going in github. What should my next steps be?
Next time you should just push your changes from your branch to the remote repository, then submit a "pull request" for the branch back into master where the code can be reviewed prior to merging.
When you push changes to your branch, to compare your changes, go to that branch and look for this near the top in the code tab:
This is some good reading as well about how/when to use forking & pull requests: https://help.github.com/articles/using-pull-requests
EDIT:
And since you did say this is after the fact, the other thing you can do is go to the master branch->commits section, and click on the commit where you merged your branch in. That page allows you to make comments and view the changed files, so you can still review your code before you actually push it to your server. However, you should still do the other way next time.
To clarify...you can branch locally and then change, commit etc, and then push that branch to GitHub, then fire off a pull request?
Yes, and since August 14th 2018, you don't even need to switch to the Code tab:
When you push branches while using the “Pull requests” tab, GitHub will now display the dynamic “Compare and pull request” widget—so you can quickly create a pull request without having to switch back to the “Code” tab.
Learn more about pull requests in our documentation.
I forked some project and cloned it locally. Changed files, commited changes, pushed changes and changes were either implemented or rejected. Then, some time has passed so I fetched/merged my fork with the project I forked from. Made some changes, commited and pushed. Sent pull request and that's where the problem begins: in pull request there are commits which were implemented or rejected and I don't want to send them to master owner, I just want to send new ones.
Am I doing something wrong? How can I fix this?
What I do is create a new, clean branch based on upstream, and then cherry-pick the changes I want to submit onto that branch (or develop them on that branch in the first place, or use some other method to copy them over to that branch).
It can look a bit silly to have a list of public branches called "clean1", "clean2" or whatever, but hopefully you won't need to make too many of these.
Alternatively, you could just submit patches instead of pull requests.