I have created one branch (Sprint1) from master and created one branch (JIRA1) from Sprint1 branch. We have did some commit in Sprint1 and also in JIRA1 branch. We thought that we can not complete development of JIRA1 and we need to merge the Sprint1 with master branch. We want to start development new Sprint2 with new branch Sprint2.
What is best practice to handle such scenario? Can i merge JIRA1 after development in sprint2 branch?
As you have mentioned merge in the question, I don't think you would want to rebase.
Instead, you can merge JIRA1 in SPRINT2 anytime you want.It won't be a problem since (Assuming you have merged SPRINT1 into SPRINT2 or SPRINT2 was created based on SPRINT1) the code base for Sprint 1 and Jira1 is same.
The problem would occur if you try to merge sprint 2 into Jira 1. In that case, you can use git rebase for specific commits of sprint 2.
Sure just merge the changes in Sprint1 to master, and rebase the JIRA1 branch onto the Sprint2 branch using rebase --onto
git checkout develop
git merge Sprint1
git checkout -b Sprint2
git checkout JIRA1
git rebase --onto Sprint2 Sprint1 JIRA1
What this will do is figure out the changes in JIRA1 branch since it diverged from Sprint1, and replay the changes on JIRA1 branch as if it were based on Sprint2 to begin with. Makes sense?
Git rebasing reference
Related
In one of case I have created an branch and started to work on. I keep on commit & push changes in local branch but did not merge in master & neither pulled any changes from master.
Now I'm done with local branch changes. I followed derekgourlay tutorial & followed following steps to merge my project.
git fetch origin
git rebase −p origin/develop
First it game me number of conflict which was obvious but changes that I committed in my local branch those are not there after merge.
Am I missing anything. Any suggestion?
You can merge develop branch with your feature branch.
$ git checkout feature
$ git pull origin develop # pull (fetch + merge) develop branch into feature
$ git push origin HEAD # update remote/feature
When I type "git branch" i get this:
Zachs-MacBook-Pro:stocks1 zachsmith$ git branch
77e98af109bd63630b38c1f1ca3937d43715ddf4
add_bootstrap
add_stock_model
master
stocks_download
temp
* working
working#2(backup)
Does this mean i am on "working" branch of the detached head "77e98af109bd63630b38c1f1ca3937d43715ddf4"?
i want where I am now to become the new master on github, but I am not sure how to do that without merging things. basically I would be happy to just re-write the master with where I currently am.
How can I do this?
Does this mean I am on "working" branch of the detached head "77e98af109bd63630b38c1f1ca3937d43715ddf4"?
No, it just means:
you are on the working branch nammed "working"
there is another branch named "77e98af109bd63630b38c1f1ca3937d43715ddf4" (probably some mishap in the git branch command)
basically I would be happy to just re-write the master with where I currently am.
You can rename the remote master
git branch old_master origin/master
git push origin old_master
And force push your working branch
git push --force origin working:master
You would see a similar approach in "Rename master branch for both local and remote Git repositories".
You have multiple options in order to do that, one is to delete the master branch and rename your working branch as master, but you might know you can be sentenced up to 25 years of jail and death penalty for that.
You can also rename your old master branch and rename your working branch as the new master, or (my favourite way) you can use the -s ours flag so you keep your master intact and you overwrite everything from your working branch:
git checkout working
git merge -s ours master
git checkout master
git merge working
And your master now will match to your working branch.
I am new to managing code revisions and need guidance on how to merge to code sets. I have a MASTER branch with my latest UI and I have a branch called "Feature-A" with lots of Django additions + template additions to the previous UI files.
Since I am new to Github, I want to take the safest approach incase I need to revert mistakes. Should I make a new brach of master and merge Feature-A into that branch or should I merge Feature-A directly into the MASTER?
Since you're new, I would say the best approach would be to create another branch (clone of master branch) and then merge feature A into that, and see if it works. If not, keep testing feature A to make it compatible. If it works, great! Just remove that extra branch and merge feature A into the master.
I.e.,
git checkout master
Then, create a new branch (git checkout -b 'featuretest')
Now, git branch shows
* master
* featureA
* featuretest
Then, do git checkout featuretest, and git merge featureA to merge it.
If the feature works, great! Remove the branch (git checkout master; git branch -d featuretest)
and do it for real (git merge featureA)
If the feature doesn't work, go back to the feature branch (git checkout feature) and keep testing.
I have a forked project, and now the master repository has added a new branch which I want on my forked project.
Is it best practice to add the branch locally and then merge from the master repository, or is there a more correct way of doing this?
My guess is this, but I don't want to mess things up:
hg branch theNewBranch
hg pull -r theNewBranch ssh://hg#bitbucket.org/master_repository/theproject
hg merge 0011223344ff
hg commit -m "Merged in master repository branch"
There's no need to add it locally. Every commit has the branch it is on burned into it. If they have a commit on theNewBranch you'll get it.
If you want everything they have mirrored locally just do:
hg pull ssh://hg#bitbucket.org/master_repository/theproject
And if you want to merge in into your local branch do:
hg checkout mylocalbranch
hg merge theNewBranch
We ran into a problem where, if you rebase your branch on top of master and then push, the other guy who was working on your branch pulls and gets all kind of merge conflicts, because the rebase has rewritten the history and the commits are not the same as they were on the branch. Is there any way around this, assuming that the other guy has some commits he wants to push to the branch?
Others should be able to rebase the branch after your push by using
git pull --rebase
You can check the "Recovering From Upstream Rebase" section of the git rebase man page.
Basically, your colleague will have to do (considering here 'subsystem' as having been rebased):
git rebase subsystem
(if his changes are on a separate branch)
or:
git rebase --onto subsystem subsystem#{1}