NOTE: As stated before, this is a FORCED push with -f. You should then check everything looks like it aught to in git gui, and then you can push: git push -f origin master Git rebase -onto bug_fix f95ecfe // Put the commits from (but not including) f95ecfe up to master, on top of bug_fix But the cleanest thing to do is a rebase of master onto bug_fix as follows: git checkout master Personally, I prefer to use the cherry-pick command through git gui to do this step by step, instead of doing one massive rebase. There are quite a few ways of doing this. Now you need to add all the other commits onto where you currently are. Git checkout -b 'bug_fix' // It's nicer to have your head attached to a branch. If only you edit master and you want to go back in time and change the commit, and change it on master, do the following: git checkout f95ecfe If you really do want to go back in time and force master Git merge bug_fix // fast-forward master onto the bug_fix merge Git checkout master // Now we need to bring master up to where we are Git pull origin master // Pull latest code. Git checkout -b bug_fix // Create branch at the current position and check out to it (branch is pointing to f95ecfe) Git checkout f95ecfe // Move head to f95ecfe (note: HEAD is no longer on a branch! - just a commit) The work flow would then be something like: git pull origin master Git branch -d bug_fix // delete the temporary local branchĪ branched master allows you to see more clearly which commits are related, but means it can look pretty messy. Git merge bug_fix // fast-forward merge master onto bug_fix branch Git pull -rebase origin master // Pull latest code, try to rebase on top of it Git checkout -b bug_fix // Create branch and check out to it (currently pointing to the same commit as master) Git checkout master // Move head to master (and check it out) (Optionally, create a bug fix branch to work off, then delete it later, a full workflow might look something like): git pull -rebase origin master //Pull latest code Git commit -m 'Bug fix for f95ecfe (Plus more details, obviously)' That is, you do something along the lines of: git checkout master What you should do is simply add a commit fixing the file at the end of your master, and push that, identifying in the commit message which previous commit you're modifying etc. Master is then a straight line, and you don't get lots of branch merges confusing things. My preference is a linear master - so this would mean that whenever anyone pushes, they first rebase on top of master, and then push. The following is how I'd recommend dealing with your situation in these cases: Linear Master There are a few different approaches to keeping a 'nice master', depending on your preference / who you're working with. Anyone else who has pulled master will then have inconsistencies when they pull again, and have to sort them out. Otherwise, if you start reordering master, (ie you go back in time, change commits, and "force push" them), then you are effectively re-writing history. You should think of a pushed master as being sacred (unless you're the only one editing it).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |