I have created a branch from another branch. Then I come back to previous branch and work on it. Now I have switched to second branch. But this second branch don't have the new changes of first branch. I just want to update the second branch from first branch without deleting any of them.
But this second branch don't have the new changes of first branch
Switching to the second branch alone is not enough for said branch to reflect changes committed in the first branch.
You would need to git merge branch1 or, if you are the only one working on branch2: git rebase branch1 (if you want to keep a linear history).
Then, and only then, would you see branch1 changes in branch2.
⇒ The OP Waqar Ahmed proposes in the comments:
I have solved this issue but checking out branch2 and pull the branch1
Related
I have created a branch and committed to it, got it reviewed and merged with main branch. Now when I try to push another change into another commit with the same branch now I see 2 commits on the branch and if I now merge, the first commit as well as the second will get merged? why is this happening?
Is there any way to replace merge with rebase at GitHub PRs? I looked through protected branches settings but didn't find such option.
GitHub now (Feb. 2022) supports this:
More ways to keep your pull request branch up-to-date
The Update branch button on the pull request page lets you update your pull request's branch with the latest changes from the base branch.
This is useful for verifying your changes are compatible with the current version of the base branch before you merge.
Update your pull request branch by rebasing:
When your pull request's branch is out of date with the base branch, you now have the option to update it by rebasing on the latest version of the base branch.
Rebasing applies the changes from your branch onto the latest version of the base branch, resulting in a branch with a linear history since no merge commit is created.
To update by rebasing, click the drop down menu next to the Update Branch button, click Update with rebase, and then click Rebase branch.
Previously, Update branch performed a traditional merge that always resulted in a merge commit in your pull request branch. This option is still available, but now you have the choice.
Note: Because rebasing rewrites the history of the branch, if you are working with the branch locally, you will need to fetch it and do a hard reset to ensure your local branch matches the branch on GitHub.com.
Learn more about keeping your pull request in sync with the base branch.
I doubt github supports this, as you should never rebase a public branch. From the official git docs:
Rebasing (or any other form of rewriting) a branch that others have based work on is a bad idea: anyone downstream of it is forced to manually fix their history. This section explains how to do the fix from the downstream’s point of view. The real fix, however, would be to avoid rebasing the upstream in the first place.
The easiest solution would be to simply use a merge. If you don't like that for any reason, you could create a new branch from main, apply the desired changes (e.g. by using git cherry-pick, or git diff in conjunction with patch), and then delete the old branch and create a new PR. If you really want to use rebase, you can do so locally and force-push the branch, but again, that's a really bad idea as it falsifies history and breaks the branch for everybody else.
My work flow to contribute to a repo, is
Create a fork of the upstream
Clone the fork to my local
Push changes to my fork
Create a PR to merge my change into upstream
Sometimes while I am working on my change, other devs might commit their changes into the upstream, so I want to do a rebase which will bring my fork up to date. But I have noticed that in the below scenario, Rebase and Merge Commit gave me different response,
The way I tested it is as follow:
I created a fork of the upstream
I cloned my fork to my local using GitHub Desktop, and set current branch to my fork branch
I then made a change in upstream/master branch and committed it
when I clicked "Rebase current branch", it tells me the current branch is up-to-date as below:
when I clicked "Merge into current branch", it detects a change in the upstream:
upstream/master is the branch in the upstream, and muti/master is the branch in my fork.
My question is, why rebase doesn't detect any change, while the merge and commit does?
Note first that if you have access to the upstream repository, you don't have to fork it in order to push a fix branch and initiate a PR (Pull Request).
You can do all that directly in the upstream repository.
Second, the rebase would only work if the current branch has a divergent history from upstream/master.
If the current branch HEAD is an ancestor of upstream/master, the rebase (of the current branch on top of upstream/master) would be a no-op.
But a merge (of upstream/master into the current branch) would not, since from the point of view of the current branch, there is one commit (done in upstream/master) that it does not have.
While merging a feature branch with the master of GitHub, I have the same scenario and workflow as mentioned in the below question :
Merge non-merged feature branch into another feature branch with Git
I have the master branch. Feature branch1 and the development for feature branch1 is already completed, the code needs to be reviewed and branch should be merged.
Meanwhile, a feature branch branch2 gets created and a piece of work for branch2 depends on code developed in branch1. Since the same code needed in branch2, I have merged and committed the changes in the master branch from branch1 once code review is completed.
Now, I am supposed to get the latest code of master branch in branch2 to start my work in branch2. So, I have merged my feature branch2 again from the master branch.
Is this the correct way to do it, or do I need to delete my feature branch2 and create a new branch again?
Also, since my branch2 was merged from master branch after it was created, when I pushed my changes, that merge was maintained as a history of that branch that will ultimately go to the history of my master branch(as a comment if I do Squash and merge), which is fine.
Now, feature branch2 shows conflicts instead of saying automatically merge. Was this due to the branch1 merge done previously? If so, is there any way to get an automatic merge option into the master branch without any need to resolve conflicts. As I am sure I have already merged the changes from my master branch into feature branch2.
When using Mercurial, assume you are using a 'default' branch. You work by creating new branches from this and merging them back into 'default' (when your work on that new branch is finished).
After merging a new branch (call it 'myBranch') back into 'default', you actually decide you need to work on 'myBranch'. 'myBranch' has not since been closed. What is the best to go about working on 'myBranch'?
Merging of branch (in Mercurial) doesn't mean it will become closed|disappeared. Used ranch is permanent part of Mercurial changeset forever
Merge will not close branch, just remove HEAD of merged branch
Because Mercurial's history is DAG, you can always return (hg up CS-ID) to any entry (changeset) in it and start working from this point, adding new child changeset on commit
For named branches, branchname is CS-ID of HEAD of latest (topologically) changeset of this branch
For LTB "Cleanup" I used hg up Cleanup after each merge it to Default branch
Nothing extra to do. If you want to continue from the last commit in myBranch do:
hg checkout myBranch # checks out last commit in myBranch
...hack...
hg commit # creates a new commit on myBranch
If, instead, you want to re-open myBranch with whatever is currently on deafult (rare) you do:
hg checkout default
hg branch --force myBranch # says "next commit should be on branch myBranch and I don't care if there already was one"
...hack...
hg commit
You probably want the first.