Code Chewing Guides

  • How to fix Git rebase merge conflicts


    Dealing with merge conflicts that arise from a Git rebase can certainly be intimidating, especially for beginners. The merge conflict alone can be tricky enough to deal with, and handling this from a rebase attempt differs slightly from a normal Git merge.

    It's important to understand the basic commands to help step through the sticky tar pit, that is the merge conflicts, and come through feeling confident that all issues have been adequately investigated and resolved.

    When confronting merge conflicts with a Git rebase, or otherwise, when you're unsure as to how it can be confidently resolved, a diligent software engineering practice is to go and speak to the person that authored the code you're trying to merge with (if practical). Nothing can beat good communication here.

    Read more
  • How to do a Git rebase


    Rebasing rather than merging provides a cleaner history. This is very useful for developers that are required to comprehend and analyse the introduced features and changes into a shared, possibly public, branch.

    It's especially useful for those who are responsible for maintaining release branches, as changes will inevitably introduce regressions over time, which will need to be quickly identified and reverted as necessary.

    It's worth noting that rebasing should mostly occur on your private branches, due to the fact you're re-writing history. If you're collaborating with other teammates on a public branch, you should avoid rebasing (until the end) to avoid friction, loss of work, and unnecessary overhead. This also holds true when updating pull requests based on reviewer feedback - the reviewer(s) want to see your incremental changes pushed up - so save the rebase until the end, when it's ready for merging. Your fellow teammates will appreciate this.

    Read more
  • How to create a new branch in Git

    This quick guide assumes creating a new git branch from the command line.

    For example, you've made some changes to an existing branch, but have decided these code changes would be better off in a new branch. Assuming that you haven't yet committed these changes in the current branch, you can effectively switch these changes into a new branch, with the following Git command:

    $ git checkout -b branch_name

    Executing git status will reveal your new branch destination. From here, you'll probably want to commit and push the new branch up to the remote repository!


    Read more
  • How to run a command from history - Linux

    Sometimes !! to execute the last command (albeit brilliantly convenient), isn't what you want. Instead, this is how to list all your recent history commands and cherry picking the command you want to execute again:

    $ history
      369  git pull origin master
      370  sudo docker-compose build
      371  sudo docker-compose stop
      372  sudo docker-compose up -d
      373  sudo docker-compose ps
      374  sudo docker-compose stop
      375  sudo docker-compose up -d
      376  exit

    Suppose I want to run the command located at 370 again:

    $ !370
      sudo docker-compose build

    ! followed by the number in history. Easy.

    Read more
  • Horizontal scroll fix for pre HTML with Bootstrap CSS

    When using Bootstrap CSS and <pre>/<code> blocks for sample code, I disappointingly discovered the the code block wasn't horizontally scrolling, and I ended up with a big mess of wrapped code for smaller screen sizes.

    For example, you might have some wide spanning HTML like the following snippet:

    <pre><code>$ docker-compose ps
       Name                Command                State                    Ports                   
    app_mysql_1 mysqld      Up      3306/tcp                                 
    app_site_1    docker-php-entrypoint apac ...   Up>443/tcp,>80/tcp 

    And it rendered like this:

    pre html wrap fix - bootstrap css

    Read more
Code Chewing Twitter