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.
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.
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
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!
!! 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 sudo docker-compose build ...
! followed by the number in history. Easy.
preHTML with Bootstrap CSS
When using Bootstrap CSS and
<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 docker-entrypoint.sh mysqld Up 3306/tcp app_site_1 docker-php-entrypoint apac ... Up 0.0.0.0:443->443/tcp, 0.0.0.0:80->80/tcp ...</code></pre>
And it rendered like this: