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}
Related
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
I am using eclipse, git and github. A friend of mine forked my github repo and changed some code. There was a pull request, I accepted the changes to my github repo. Now I tried to commit my own files and I am not able to 'commit and push'. As you can see in my screenshot there are no visible differences in the file. What procedure will solve this conflict?
Assuming your friend's work got merged into master and you are on branch your-feature-branch then:
git checkout master
git pull
git checkout your-feature-branch
git rebase master
will attempt to rebase your work on top of master, which already includes your friend's changes. The rebase procedure will process your commits one at a time and inform you of any conflicts which you can then resolve. Each file with conflicts will have conflict markers that tell you the changes introduced by each branch. After resolving the conflicts stage your changes then do
git rebase --continue
Repeat until rebase finishes. If at any point you become confused you can always abandon the rebase with
git rebase --abort
Once your work is rebased push your-feature-branch to origin, open a pull request, then merge.
I got the same issue sometimes, without a visible reason. Using a git rm on the directory containing the bad file, followed by a git reset --hard solved the issue for me.
git rm --cached -r DIRECTORY
git reset --hard
Can anyone please help me out doing a rebase on git?
It's really confusing, I'm not able to understand its functionality.
I want to rebase branch on master origin.
How do I do that? I also want to squash commits into one.
Take a look at the manual here.
Swith on your branch:
git checkout myBranch
Rebase it on your master:
git rebase master
If you want to squash some commits (for example on the last 10 commits) you've do an interactive rebase while you're on your branch:
git rebase -i HEAD~10
Then in your editor you can use the squash keyword to meld a commit in it previous commit.
I have a git branch "dev". Branch "master" is reachable from dev. While on branch "dev", if I type "git log master..dev --pretty=oneline" it clearly shows that master is reachable (104 commits earlier). But if I type "git rebase master", it will stop with conflicts. Why is that? Shouldn't rebase have nothing to do in this case, since dev is already based on master?
The reason I am asking this is because I really want to do an interactive rebase with squashes and rewords to clean up a lengthy history. But I am put off by having to resolve all the conflicts that should have already been resolved once I start the rebase.
The following are some related questions that I've already looked at:
Why does git-rebase give me merge conflicts when all I'm doing is squashing commits?
Conflicts with `git rebase`
git rebase master rebases your branch to be based off the latest commit in master. If you want to base it off something earlier, you need to specify the exact commit, i.e.
git rebase `git merge-base master HEAD`
rebase != merge
If you just want to fast forward, use
git pull --ff-only ...
git merge --ff-only ...
If you want to 'automatically rebase/fastforward' depending on the current context and relationship of your branches, I suppose this would work:
git pull --rebase ...
You may want to read the man page on what it does, precisely
http://gitready.com/advanced/2009/02/11/pull-with-rebase.html
http://longair.net/blog/2009/04/16/git-fetch-and-merge/
This is my current git-svn workflow:
git checkout -b feature master
# hack commit hack commit
git checkout master
git svn rebase
git merge feature
git svn dcommit
This usually works fine, git replays at the trunk all the commits from the local branch, and the only 'lost data' are the original commit's timestamps, no big deal.
But it looks like today there was something different about the merge and dcommit that caused the commit message on the SVN repo to be simply "Merge branch 'feature'", maybe because the feature was 'smaller', with only 2 or 3 commits.
How can I avoid this to happen and ensure that all commits and commit messages from git are replayed on the SVN repo?
That comment should be the result of a dcommit of a git merge, as illustrated in "Is git-svn dcommit after merging in git dangerous?":
(master)$> git log --graph --oneline --decorate
* 56a779b (work, master) Merge branch 'work'
|\
| * af6f7ae msg 3
| * 8750643 msg 2
| * 08464ae msg 1
|/
* 21e20fa (git-svn) last svn commit
In other words, if those three "msgx" commits had been done directly on master, they would have been replayed (with their original comments) on the svn side.
But here, only the resulting merge commit gets replayed, with the "generic" comment on it.
You will need to rebase from the feature branch first:
git checkout feature
git rebase master
This ensures that when you merge into your master, you only get a Fast-Forward rather than an actual merge.
My flow is usually more like this:
git checkout master
git svn rebase
git checkout feature
<hack...hack...hack>
git commit
git rebase master
git checkout master
git merge feature
I just make sure to do an svn rebase and then rebase all my feature branches to keep everything nice and linear the way that SVN likes it.
Also, if you're not aware of it, there is the git svn dcommit --dry-run option. I always use --dry-run and count the number of commits to make sure that git-svn is going to commit what I expect.