• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

git rebasing methods

 
Ranch Hand
Posts: 83
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So, I've been doing some research on git rebasing as I'm the only person working on my branch and I'd like to avoid merge conflicts before the merge request finds them. I've found 2 methods using command line and I'm confused about the commands and if one is safer to use than the other. Then of course there's using merge from develop instead, but at least one of these recommends rebasing everyday.

One step that neither mentions is that if there are changes I've made that I do NOT want to commit that I need to stash them.

One method is from

git Rebase how to use it properly.

and it's steps are:
• go to your feature branch
• git fetch
• git rebase -i origin/develop. (NOTE: i don't fully understand what this command does... Is it pulling the newest from remote develop or just my local?)
• it will open the editor and remove all commits that are NOT yours
• then close the editor
• if there are conflicts, fix it manually, save and commit it
• git rebase — continue
• #important, don’t do any git pull to merge from remote
• git push — force-with-lease (overwrite the remote even there is divergent) (NOTE: this seems dangerous)


the 2nd is from git Best practices

It's steps are:
  • # grab the latest stuff from origin/master to update your local master branch
         > git checkout master
         > git pull origin master
  • # go back to MYBRANCH and now rebase with the changes in your local master branch
    >. git checkout MYBRANCH
    > git rebase master
  • # if you encounter merge conflicts… edit each affected file, then git add that file.  Then
    >  git rebase --continue
  • [list]# commit your updated branch to origin.  May require a -ff to force.
    >. git push origin MYBRANCH
    [/list/


    What steps do you prefer to ensure that your branch will merge?
     
    Saloon Keeper
    Posts: 13280
    292
    • Likes 2
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Karina Guenther wrote:So, I've been doing some research on git rebasing as I'm the only person working on my branch and I'd like to avoid merge conflicts before the merge request finds them.


    If you're the only one working on your branch, you shouldn't have any merge conflicts while you're working on it. If you're worried about merge conflicts when you merge your feature branch into another branch, git rebase isn't going to help you more than an old-fashioned merge will.

    at least one of these recommends rebasing everyday.


    Terrible advice. Rebasing is good in two scenarios:

    1) You KNOW you're the only one working on a branch (work means having checked out a branch, not necessarily also committing to it) and you want to clean up your commit history before you make a pull request.

    2) You have a bunch of separate commits locally that you haven't pushed yet, and you want to clean up your commit history before you push.

    Both of these situations are pretty rare: How often do you make pull requests? Why do you have many commits that haven't been synced to the remote server? Rebasing should be a rare occurrence, not a daily habit.

    • git rebase -i origin/develop. (NOTE: i don't fully understand what this command does... Is it pulling the newest from remote develop or just my local?)


    It rebases your currently checked out branch on top of your local view of the develop branch on the remote server.

    origin/develop is NOT the same as develop. develop is a local branch you can perform work on. origin/develop is a local view of what your machine thinks is on the remote server.

    The command says: "Ignore any commits I might have made on develop locally, rebase my current branch on whatever you think is the current state of the develop branch on the remote server".

    It's very important that you perform a git fetch before you rebase on origin/development, because it ensures that your local view of origin/development is really up to date with what is on the remote server.

    The -i switch makes the rebase interactive. Git will find all commits that are NOT already in the origin/development branch, and puts them in a text editor using a certain format. You can rearrange the commits in your text editor and prefix them with special commands to tell Git what you want to happen to all commits that aren't in origin/development yet.

    • it will open the editor and remove all commits that are NOT yours


    This is absolutely WRONG. Let's say that you've merged commits from features/cool-feature-1 into your current branch, which is features/my-new-feature, then commits that are in features/cool-feature-1 that were made by other developers will also appear in the interactive rebase, as long as they aren't already part of the branch you're rebasing on (origin/development).

    • #important, don’t do any git pull to merge from remote


    Again, absolute BS. Interactive rebase works just fine even if you're merged remote work into your current branch. You just need to use the rebase command correctly.

    • git push — force-with-lease (overwrite the remote even there is divergent) (NOTE: this seems dangerous)


    It seems dangerous because it IS dangerous. --force-with-lease makes sure that you don't overwrite work of other people, but you can lose your own work very easily. This is also the reason why in general, you shouldn't rebase, and just use merge all the time.

    the 2nd is from


    The second one is a bit better, but personally I still prefer an interactive rebase because you have a better idea of what the rebase is doing.

    My advice to you is, if you want to learn how to rebase, practice with dummy branches that you don't mind messing up. Practice practice practice until you are comfortable with rebasing, and then find a workflow that works for you.

    What steps do you prefer to ensure that your branch will merge?


    Just merge the target branch into your feature branch before you make a pull request. If there are any merge-conflicts, you will get them regardless of whether you perform a rebase or a merge. When you're completely done with your feature branch, you can usually tell the version control software how it should finish the pull request. You have several options:

    Merge: Use this when in doubt.

    Rebase: Use this when you're the only person that has checked out the branch you're trying to merge, and you don't mind deleting the branch after the pull request is complete. This will linearize the work you've done relative to the target branch (it will throw away merge-commits) and replay all your commits on top of the target branch. DELETE THE FEATURE BRANCH AFTER THE PULL REQUEST IS COMPLETE.

    Squash: This is like rebase, except it squashes all your commits together into a single commit. This is useful if your feature is very small, and you want a neat commit that encompasses all the changes. Usually used for bugfixes. DELETE THE FEATURE BRANCH AFTER THE PULL REQUEST IS COMPLETE.

    The reason you must delete the feature branch after performing a rebase or squash is because the commits that are merged to the target branch will not be the same commits that are on your feature branch. If you or a coworker continues work on the feature branch and tries to merge with the target branch at a later stage, you will end up in merge-hell. Delete the branch to prevent anybody from ending up in this situation.
     
    Karina Guenther
    Ranch Hand
    Posts: 83
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks so much for the detailed explanation. You verified some of what I was thinking. Yes at this time I am the only person on my branch. Furthermore, they have it setup that when a pull request is succesfully completed and the branch is merged it is deleted and I'm trying to keep my local branches clean as well.  Do you have a favorite location with clear - precise steps / commands for reference?

     
    Saloon Keeper
    Posts: 24321
    167
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I did an inspection of my own git archives a while back and one of the things I determined was that git history doesn't really take up that much space.

    So while I'm pretty obsessive about keeping things clean, I decided that packing down changes and deleting old history wasn't generally worth the trouble - or the risk - for me.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 13280
    292
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Karina Guenther wrote:Do you have a favorite location with clear - precise steps / commands for reference?


    I just have my personal workflow, which is quite simple and which I know by heart.

    For beginners, I recommend https://learngitbranching.js.org/ to get a hang of some of the basic commands, as well as a couple of advanced commands.

    For reference, just look at the git manual. It is well written and Git will automatically direct your browser to the appropriate page when you type "git <command> --help".
    reply
      Bookmark Topic Watch Topic
    • New Topic