I need to come to the state before rebase.
The following command gives the error, which makes sense. My rebasing was successful.
git rebase --abort
No rebase in progress?
Any idea?
In the general case, if you completed your rebase, then your branch is now sitting on a new base of one or more commits, and you may have reworked some of the commits which were already on the branch, as you reapplied them.
One possible fix here would be to just reset your branch to the remote tracking branch:
git reset --hard origin/feature
Note that this option would only make sense if you have not made any new commits since you last pulled. Assuming this, the tracking branch would serve as a sort of backup of the branch before you did the unwanted rebase.
Related
I'm currently working on an assignment where we work on a local repository and push to a remote repository when we are done. We are expected to make use of branches, wherein we make all our commits before merging it into our master branch, so no commits directly to the master branch.
Everything was going fine, but I've come across a problem when I made some commits on a branch, then merged that branch into my master, before going back to the before-mentioned branch to make some more changes, committing them and merging it once again back into my master branch.
My network tree is currently looking like this:
network branch
The problem being the green branch that is branching off at the end with hash 2bbbd0c.
I'm essentially looking to undo that commit completely and simply have my branch merge into my master, so my network branch shows that nothing is branching off.
One idea I have is to use git reset –hard 2b32611 (which is the hash for my latest commit on the branch before merging it into my master):
enter image description here
And then to use git push -f origin 2b32611:cookies-user-tracking to push the commit and the branch, but once again I’m not sure if that’ll work, and I don’t want to mess anything up.
The git reset --hard will indeed reset cookies-user-tracking to the right commit (before merge)
All you need to do then is to force push the branch:
git push -f origin cookies-user-tracking
So this isn't your typical 'just rebase' issue (Atleast I don't think).
I'd like to know how I can create more than one pull request without effecting past commits. Here is my current scenario:
I forked a repository
I made the change on my local master (so stupid, I know)
I made a PR with the changes
They were accepted but are auto-merged by a bot in a few days
Here's the problem, I'd like to keep contributing but with individual PR's in the meantime that don't list all the old (but yet to be merged) commits I've made. My idea was to get upstream, rebase my master, and work from there (properly this time with branches). However upstream/master conflicts with master so it won't allow me to. I'm afraid to rebase my local master with the current original because I fear it may 'delete' the code for my pull request and somehow invalidate it.
Any idea how I can fix this? Or do I just have to wait for the bot to make the merge from my PR then rebase from master.
My idea was to get upstream, rebase my master
Don't: set a branch on your current local master, where you have your old (but yet to be merged) commit.
git switch -c mywip master
(wip: work in progress)
This uses the new git switch command (Git 2.23+)
Then reset master to upstream master
git fetch upstream
git switch master
git reset --hard upstream/master
Work from there, in a new branch, for a new future PR (based on a code which does not list the old -- but yet to be merged -- commits).
I can never seem to figure out how to use git. I just do random commands and it works eventually. This is what I usually do when I want to push:
Fetch from upstream
Commit
Push to upstream
However, the above steps don't work sometimes. For example, when I do fetch from upstream, my local branch doesn't get updated.
How do I merge the remote branch into my local branch? Is there a difference between pull and fetch?
"git pull" is equivalent to "git fetch" followed by "git merge"
What you want to do is:
git commit -am "your message here"
This commits your current changes locally, and only locally. Now, assuming branch "foo":
git pull origin foo
This does a "git fetch" followed by a "git merge". Everything in this step is done to your local branch, and still has no effect on the remote branch. Depending on how your git is setup, you might need to specify the branch.
If you have a merge conflict, you will have to fix the files listed, then add them back:
git add path/to/resolved.file
When you are done, push everything you have from your local changes, to the remote server:
git push origin foo
If you pull before committing, that might cause your local branch to not be updated.
tl;dr, always commit before pulling!
Well to understand differences betwene git fetch and git pull look here.
In the simplest terms, "git pull" does a "git fetch" followed by a
"git merge".
You can do a "git fetch" at any time to update your local copy of a
remote branch. This operation never changes any of your own branches
and is safe to do without changing your working copy. I have even
heard of people running "git fetch" periodically in a cron job in the
background (although I wouldn't recommend doing this).
Working with git in eclipse might be a little bit tricky, but if you understand git basics, you should cope with it. I recommend you to read one of git tutorials, so you will be able to understand basic git operations.
The first step to learn git: Don't use egit.
Now, you are fetching and pulling from upstream. That makes me think that several people have write-access to the same repository, so we probably don't want to be doing a whole lot of merges to complicate history. It would be best to do this. I'm assuming you have already committed a changes or a set of changes to your local master branch that you want to place on the upstream repository which has been pushed to by someone else while you were making your commits.
First, we fetch the new changes but don't use them yet. This updates upstream/master to the new head of the upstream master branch.
git fetch upstream master
Now, we need to pull in these changes. This command rewrites history, and we are assuming
that you have not published your changes anywhere yet.
git rebase upstream/master master
If you have published your changes, this messier command is the one you should use (do not use both, just use this one!)
git merge upstream/master master
Now, we can push:
git push upstream master
The first two steps can be shorted to git pull --rebase and git pull for the rebase and merge versions respectively.
If you are already on the master branch, most of those second arguments are superfluous but I wrote them in for clarity. Notably, giving a second argument to git-rebase or git-merge will simply check out that branch before doing the operation. Supplying master to fetch and push is only necessary if you don't have the refs set up to automatically fetch and push master.
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/
The company that I'm working is working with SVN but I would like to start working with git to take advantage of the light branching and stashing features (disclaimer, I'm pretty new to git). I've started with git-svn and I'm trying to figure out the ideal git-svn workflow for what I'm trying to do (and suggestions if what I'm trying to do needs tweaking).
I've read through git svn workflow - feature branches and merge and a few other posts but its still not clear how I should approach it.
How I plan to work:
I plan on having my master branch be clean from development and only used for merging/rebase/dcommit.
I would like break apart each new feature/bug into separate git branches so they can be worked on independently. Meaning, I can work on one feature for a few hours, then put it aside and work on the next issue. When I was in SVN it was a problem when I had two different features/bugs in one file because when it came time to commit, I would remember that it had both changes and temporarily take out what I didn't want to commit now - a pain.
And the are some features which are while I might want to work on now, will not be added to the main repo for some time.
After a feature is ready to be shared/tested in the main repo, I'll merge/rebase into my master branch and then dcommit to the svn-repo. I only want to have one SVN commit message for each dcommit - I want to be committing in more often with comments more specific to me and then dcommit to svn with a message for the rest of the team. I assume for this I'll either be using a git merge --squash or a git rebase --interactive for this.
The basic git flow I've envisioned is like this:
// it begins...
git svn clone <repo>
//
git checkout -b feature 1
// work commit, work commit
//
git checkout -b bug-123
// work commit, work commit
// bug-123 finished - ready to send back
// got back to master for step 5
git checkout master
// get whatever changes other devs did
git svn rebase
//
git checkout bug-123
// rebase branch so I have fewer smaller changes. not sure here..
git rebase master || git svn rebase
// Assuming I'm doing a FF rebase so my commits are just addons to the current repo
// I don't know if I rebase the master or svn repo or it doesn't matter.
// need to get my changes back to master to send off
git checkout master
// add my changes to master
git rebase bug-123 (--interactive?) || git merge --squash bug-123
// do I add a new commit message here?
// push my changes back out to the team
git dcommit
So there are a few questions:
How should I get the changes into the branch I want to commit - by rebasing the master or the svn branch
how do I get the changes back into the main branch - rebase or merge - remember, I want only one commit for each commit - unless this is going to complicate things - I really would prefer to keep my git commits separate from the SVN commits because I might start something - it's half-working, and want to commit it so I could try something else - but I don't want to commit these broken steps.
would it make sense to dcommit directly from the working branch (eg bug-123)?
how do I get the changes from bug-123 back now into feature-1? I'm assuming I'll do it via the SVN repo - meaning the changes that I added will get merged in when I do the rebase when it's time to add feature-1 to the repo - but maybe not.
I'm no expert, but these are the experiences I've made (related answer).
I think it doesn't matter. The important thing is that you rebase the latest changes from SVN into the branch you are going to dcommit from.
Let other branches receive the changes through SVN. If you want a single SVN commit from a series of git commits, squash them together first.
I think this doesn't matter either. You're going to rebase the latest changes from SVN, and need to get them linearly in front of your Git commits. If you do git svn rebase in master, and then rebase master into a feature branch, or the other way around is same-same. Afterwards you probably want to delete the branch, as it has done its work (as per SVN restrictions, you're not allowed to merge again).
Always let changes flow into other branches and repos through SVN rebasing.
Just try it out and try to get the most simple/practical workflow for you and your team. Try to keep branches short-lived (SVN won't get any notion of them anyway), and remember that the commits must always be linearized at the top of your log before you dcommit back.