Tag: git

  • git without merge and fetch

    [Title might be misleading because you need to make somewhere that merge but let it your github/stash/bitbucket etc. do it for you]

    Problem: When starting your adventure with git did you feel like not knowing what is going on and ending with deleting the repo and cloning once again? I wish to help you and show how to work with git without removal&clone again.

    The idea comes from Advance Git video. If you want TL;DR carry on with reading.

    Once upon a time my dear friend told me how to work with git. Since then I’m happy git user and then I saw above video confirming that way of work. Before that I was blandly merging, pushing, forcing and always left in conflict state. There are some rules worth remembering in this workflow style.
    1. rebase only
    2. always work on a branch, even if your projects doesn’t require it

    That’s it. Have a pleasant life!

    The first one keeps your history clean – one straight line, because while rebasing to any branch you “plug out” your commits, rewrite new commits (from branch you rebase against) and apply your commits on top of that!

     

    My typical work flow with git:

    1. git clone [repo]
    2. git checkout -b dev – always work on a branch, let it be dev
    3. git add . & git commit -m "whatever" – commit changes, I prefer `git cola` for previewing and commiting my changes
    4. git push origin dev – if you want to make an pull request you need to push your changes to remote repo
    5. git checkout master – switch to master
    6. git pull --rebase – pull new commits to master, let your local master branch be always a copy of that remote
    7. git checkout dev – switch to dev
    8. git rebase master – apply changes from master to your branch, conflicts may appear here, but after resolving you are synchronized with current master
    9. git push origin dev:master – this pushes your commits from your local branch dev to remote master, instead of merge, or when working with PR let it github do merge
    10. git branch -D dev – delete branch, repeat the process

    By “resolving conflicts” I mean edit that conflicted files manually and applying with `git add` them and git rebase –continue. After 8 step you can push your changes to remote repo and it will be easily merged into master, or locally you can switch to master and merge your dev branch as well.

    Shortcut for steps 5-8:

    1. git fetch origin
    2. git rebase origin master – being on dev branch

    Useful tools:

    1. for moving commits between branches use git cherry-pick

    Squashing

    I like squashing because it makes feature come in one commit, but this is quite controversial, most prefer to make a lot of smaller commits claiming that it will be easier to revert or spot a bug.

    1. after a few hours of work you’ve got 2 commits, go and squash them
      git rebase -i HEAD~2
    2. manage two steps
      1. you’ve been shown a history in reversed order so you mark `pick` first commit and mark `s` or `squash` the rest, save & quit
      2. on second screen you delete or comment out commit messages and leave just one
    3. you could refresh your master branch by pulling changes like in step 2., after that please get back to git checkout MyDevPolygon
    4. rebase your changes to master by git rebase -i master
    5. you will be shown your squashed commit ready for commits, if git tells you about any conflicts, you will have to resolve them but only once!

    Sometimes people are working on branches to which they merge changes from master (acquiring new design)… in the end they go back with their work to master.

    In this common case you might need to apply one of following scenarios:

    1. BEST: always keeping your changes on top – rebasing to master while working on feature branch
    2. when you messed smth up and git asks you to resolve same conflicts over and over go and use
      git rerere
    3. at the end squash your changes two one clean commit

    I love this article git team workflow merge or rebase

  • Git Kata 2

    Git Kata 2

    Hi, I’ve dropped by just to invite you to Git Kata 2 (git workshop in kata format) meeting in Warsaw, Poland on Dec 8, 2013.

    I will try to convince people to use legit and github. I will describe shortly my participation in fabtools – opensource project.

    All details may be found here

     

    Here I am

  • GWT 2.3, Git and Mercurial

    GWT 2.3 was released on May 2, 2011 a few days before Google I/O — May 10. Without doubt there would be some talk about news in GWT. I am curious if GWT RPC XSRF protection is really securing rpc connections. I will try it out.
    I participate a few important projects for my company and see there is just mess in my versions and code while working with subversion that is why I am looking for something better — DISTRIBUTED VERSION CONTROL. I’ve already installed EGIT for my eclipse. (I’ve been on a meeting with one developer of it Darius Luksza — nice tool btw) and it impressed me. As I work more with netbeans I found there in options a panel for mercurial. I know that people in polidea.pl are using it. As they are impressing iPhone, Android developers having lights with their jenkings/hudson status projects in office I believe they know what are doing and they became some kind of gurus to me. So I will follow them too. Here are two fine tuts with getting started with mercurial. Using Mercurial to work with NetBeans Sources in the IDE, and Mercurial User Guide. Except anything else I hope this will make my work more comfortable and will bring some order in the code.