You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
We use a Git branch for our work; let's name it Branch_A
How do I do that?
Thanks @Saxea _Flowie_ . Will try this.
Always a little nervous to try things like that in a real, super utilized, BitBucket hosted repo environment. I'll read more on rebase and I'll try it in a set of test repos first.
Is there anything I should be watching for that could cause problems?
You can create a backup of your branch before rebasing and also check the log to make sure it looks like how you expect before pushing:
git checkout Branch_B
git checkout -b Branch_B_backup
git rebase Branch_A
git log --graph --oneline --all
git push origin Branch_B --force
The critical part is the push force which will rewrite the branch remotely.
One thing that can go wrong is if you have conflicts. Then you need to resolve them and do a `git rebase --continue`
Lastly, the commits in this branch will be re-created, so if it's been shared with other team members, you will need to let them know that it has been rebased. So they can adjust their local copies too, by pulling your new commits. There are different ways to handle this, but possibly the simplest is to make sure everyone pushes their changes. You pull their changes, rebase and push. They can then reset their branches: `git reset --hard origin/Branch_B`
I'm not worried about Branch_B. I'm worried about Branch_A. So I assume that as long as no push is done, all changes are local and as you say the push --force is the critical point. The problem I see is that there's people all over that might be doing something in the Branch_A as I push --force.
I might not even know of their existence... And for sure can't ask them to do anything specific.
The Git repo is hosted on a BitBucket corporate server.
The problem originates from the fact that I created Branch_B sooner than I should have done *and* that the Branch_B is tied to a Jira ticket on which I'd push my changes and create a pull request to get the commit approved.
Is there a way to "disconnect" the branch (Branch_B in this case) from the Jira ticket, recreate a new branch, say Branch_C, and "connect" that Branch_C to the Jira ticket?
For the moment my work-around was to create a sub-task of the Jira ticket, create a new branch where I committed my changes, pushed them and create the pull request to Branch_A. But that requires an extra Jira ticket.
I did miss 'I don't commit anything in Branch_B'. In this case you could just do a `git pull` and it would be in sync with Branch_A.
Yeah, all changes are local before pushing.
Re "disconnect", it depends how this is being done in your case. A common way to "connect" or link PRs to Jira tickets is via a reference in the commit message to the ticket. If that is your case a new branch would also work.
Keep in mind that some aspects are particular to your organization, so you might want to ask someone within your org too.
I used to be quite involved with the way Jira worked where I worked before. But now I sub-contract and asking for the type of info related to the relationship between the Git branch and the Jira ticket did not get me anywhere as I'm not able to find the right person that would know...
And, no. A git pull does not solve my problem. If I pull from Branch_A I'll get the new commits, new branch points from that branch but it won't change the branch-off point where I created the Branch_B. And that's what I want to change.
The real solution would be to delete the Branch_B, recreate it and associate it with the Jita ticket. I was hoping to find a Git only solution but there might not be one.