Currently i'v forked some repo on github.
Changed something for my needs, pushed to my master branch, changed something related to core master branch.
Now i want to "pull request" these ( last ) commit only to core master branch, but when i create pull request it has 2 commits in it.
I need a solution, wich will allow me to "pull request" only 1 commit trought GitHub Website or GitHub for Windows app.
I'v read about git cherry pick, but these solution requires cmd/git atc.
But what i need: Website or Windows app to do that.
Related
I am newbie using Gerrit review flow and previously had good experience in GitHub and GitLab.
But looks Gerrit review system works bit different.
So I have created one feature branch called feature/test. This branch contains one test commit and this commit has been pushed to Gerrit.
Change can be seen Gerrit with unique change id and commit.
Now the problem is, on this feature branch 3 developers will work and they need to continuously fetch each other changes with same change id.
Can someone help on this, what I need to do. because when I pulled this feature branch with one test commit then change is not visible to me at different place.
I didn't understand what you mean by "fetch each other changes WITH SAME CHANGE ID". A Change-Id is a unique number that identifies a change in Gerrit. Each change made by each developer will have different Change-Ids.
The better process to work on Gerrit is the following:
1- Update the local repository
git fetch
2- Create a work branch based on the remote branch:
git checkout -b work1 origin/feature/test
3- Make your change and commit
git add
git commit
4- Push your change to review on Gerrit:
git push origin HEAD:refs/for/feature/test
If the reviewer suggests something to do:
1- Checkout the work branch
git checkout work1
2- Fix your change and commit
git add
git commit --amend
3- Push the fix to Gerrit:
git push origin HEAD:refs/for/feature/test
All developers can work in parallel using the same process. You can also work in parallel by creating other work branches (work2, work3, etc) while is waiting for review. Avoid serializing the commits by always basing your work branches in the remote branch and not in your previous work branch.
When the feature branch is read, it can be merged in the master (main, release, or whatever it is called) branch.
Been using production/integration branches to manage code promo to production. Our integration branch is a stable integration environment that all feature branches are made from, and merges are reviewed by PR, and deployed via CI when approved and squashed+merged. Once integration is stable and we've tested it, we do another PR from integration to production. When this is approved and squashed+merged, CI takes over and deploys to the production env.
git checkout integration
git checkout -b feature
# do work
git add/commit etc
# create PR, squash+merge on github UI when reviewed
# CI sees new commit to integration, deploys to int env
My issue is with what these integration -> production PRs looks like when they are reviewed - even though (at times) I've done the following to get any commits already in production into integration:
git checkout integration
git pull
git pull origin production
git push
# create PR for integration merge into production
When I go look at the PR page on Github, the list of commits shows history going back to commits that are already represented in production. The "Files changed" list is very small, while the commit history goes back many PRs ago. I thought git pull origin production would remove this history and then only show the new commits coming from integration to production?
Am I missing some obvious way to maintain merge commits but also clean up the history when integration is merged into production? Could inconsistent merging/rebasing strategies cause this?
Some screenshots to show what is confusing - a PR that has a single file changed from a single commit, but the commit history goes back much further:
The single file change was the last commit in the list—why does the PR show commits that have already been merged previously? I thought Squashing and Merging (both into integration from feature branches and into master from integration would remove this commit history and make merges into master clean?
The green arrow represents the 1 file changed in this PR, and I thought the commit history (after a merge of production back into integration to clean the history, if any) would only have that one commit.
Is this a github display bug or am I missing some principle of how git maintains commit history across a long-running branch that gets merged into another long running branch? It's always a one-way merge, from integration into production branch, for CI to deploy the update.
Can anyone explain why a commit in GitHub would display the following information : 'Contributor-A' committed with 'Contributor-B' on 15 Feb.
Does it mean that 'Contributor-A' is the author (who does not have the push access to the master) and 'Contributor-B' is the committer/maintainer?
Then why isn't there a PR created for merging this commit? Or does it mean that there was a closed PR about this commit, but the maintainer did not merge it via web interface but performed rebase or cherry-picking to include it?
Many thanks!
...maintainer did not merge it via web interface but performed rebase or cherry-picking to include it?
I was able to get this by cherry-picking a commit from another branch and directly pushing to the current branch - an example on GitHub.
A Pull Request is not required to push code between branches. A Pull Request is a method that allows developers to collaborate on changes prior to merging between branches.
For sure, it happens when the pull request was merged by "Rebase and Merge" strategy via the web interface, but I'm not sure if this is the unique case.
Contributor-A committed with Contributor-B on 15 Feb.
Contributor-A submitted the pull request and Contributor-B effectively merged it.
It might happen in other scenarios as described here: how to apply a git patch as if the author committed to my repo?
I have 2 branches - master and develop
I have been doing some pull requests in my develop branch where it contains 5 items, in which it is the same as the number of items in master.
However, someone did some commits and pushed in a few more items into the master branch, and hence now it has 8 items.
As my pull request in the develop is still not yet approved/merged, whenever I tried to update my pull request, I am getting the message stating that This pull request can't be merged. You will need to resolve conflicts to be able to merge and asked me to do the following:
git fetch origin master
git checkout develop
git merge FETCH_HEAD
git commit
git push origin HEAD
And this happens after I have 'pushed' out my commits, making me confused at times. Then I realized that it is asking me to re-add and re-commit in the additional 3 new items. So does this means I must ensure that the items and contents between these 2 branches of mine should be the same as always? I have always used git pull/fetch but will there be a better way for me to make sure?
What this means is that GitHub would like to merge your PR branch into master, but it can't, because there are conflicts. As you've discussed in the question comments, the best way to deal with this (usually) is to merge your master branch into develop on the command line. That will show you the conflicts and ask you to resolve them. Once you've completed and pushed that merge, the PR will be mergeable back into master using the green button on GitHub.
You could simply merge your deploy branch into master (which I realize sounds a bit more sensible). In that case, you'd be bypassing the PR entirely. You'd have to close the PR "unmerged", and separately you'd manually push the merge commit to master.
By doing it the first way,
you make a better audit trail by merging to master on GitHub, using the PR;
you give your team a chance to review your code after the merge, before it lands on master; and
if you have automatic tests (such as Travis CI or CircleCI) which check PRs, you give them a chance to run your merged code as well.
Say I have a repo and someone forks it. Then they do work and submit a pull request. But the code contains a large number of lines and/or it creates a GUI. I'd like to fetch it so I can actually see it run from Eclipse before merging it into my master. The options I've come up with are:
Create a second repo in EGit and clone directly from their fork.
Create a new branch just for them. Then leave a comment for the request asking them to re-submit the pull request using the new branch and that I'll be closing the current request (without merging)
Always keep around a branch for them to use in their pull requests.
Besides setting up an organization on Github what else could I do?
Then leave a comment for the request asking them to re-submit the pull request using the new branch and that I'll be closing the current request
They don't have to re-submit, it you test and merge first locally, as described in the "Merging a pull request" GitHub page.
git checkout master
git pull https://github.com/otheruser/repo.git branchname
If the local merge works, then you can go ahead and merge the pull request through the GitHub web interface.
GitHub has documented how to checkout a pull request.
As I have illustrated before in "What support for git namespaces exists in git hosting services", you can use refs/pull/<PRNumber>/head as remote pull reference, in command line or in Egit when, for instance, creating a new branch.
If the PR number is 123, you can simply use the EGit Pull action, and use pulls/123/head as reference.