Marketing – redpanthers.co / Red Panthers - Experts in Ruby on Rails, System Design and Vue.js Mon, 29 Apr 2019 11:28:11 +0000 en-US hourly 1 https://wordpress.org/?v=5.2.7 GIT CHERRY PICK /git-cherry-pick/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16161 ]]> What is cherry picking? Cherry picking is to choose a commit from one branch and apply it to another. The command used is git cherry–pick , and here we actually use forward- or back-port commits from a maintenance branch to a development branch.cherry-pickcommand in git allows us to copy only one commit at a time.

Steps on git cherry-picking:

  1. If you are on a particular branch and you want to apply a commit to the master branch, then checkout to master branch : git checkout master
  2. Then run the cherry-pick command : git cherry-pick <commit-hash>
  3. If you cherry-pick from a public branch, then you should use this, git cherry-pick -x <commit-hash> which will generate a standardized commit message.
  4. If you have notes attached to the commit they do not follow the cherry-pick, to bring them over as well, you have to use: git notes copy <from> <to>
  5. A range of commits : git cherry-pick start_commit~..end_commit
  6. Multiple commits (non-sequential) : git cherry-pick commit_1 commit_2

 Sequencer Subcommands

Cherry-pick uses continue, quit and abort subcommands in git.The continue command is used for continuing the operation in progress using .git/sequencer information.It can be also used to continue operations after resolving conflicts in a failed cherry-pick.The quit command forget about the current operation in progress and can be used to clear the sequencer state after a failed cherry-pick.And finally, the abort command cancels the operation and return to the pre-sequence state.

Where can cherry-picking be applied?

Whenever defect occurs in the production, fixation must be performed. Once the defect is fixed, you’ll want to bring this code change back to the development branch so the defect won’t be re-introduced into production with a future update.The first option is to consider whether a simple git merge would work. If a merge is possible, that would be the ideal solution. However, if there are other changes made on the production branch, shouldn’t be brought back to the development branch, a merge would not produce the desired result since it will include all the changes made to the production branch. Example: Figure 1: Problem is found in the Production branch. A fix for the problem is developed in commit H, but commit G does not need to be applied to the Development branch. Problem Is Found On Production Branch Figure 2: Commit H is cherry-picked onto the Development branch, resulting in commit H’. Note that the changes made in commit G are not included on the Development branch.

Results In Commit H

What git cherry-pick does? It takes a commit from somewhere else, and “play it back” wherever you are right now.It can be explained by an example given below:

Figure :3

  Consider you were at node H in this graph, and you typed, git cherry-pick Eyou’d wind up with a copy of commit E—let’s call it “E prime” or E’—that pointed to H as its parent, and can be represented as,

Figure: 4

fig:b
And if you typed,git cherry-pick C D E then the graph can be as,

Figure: 5

From this graph, we can infer that git has copied changes made in one place, and replayed them somewhere else.
 If H is in the production and we are taking the difference  from B to C and apply to H, the C prime (C’) can be obtained to H, same way after cherry-picking  D and E obtains  D’ and E’, and this can be diagrammatically represented as in the Figure: 5
 
]]>

]]> Setting up your own private GIT server /setting-up-your-own-private-git-server/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16369 ]]> git user and a .ssh directory for the user. Follow the commands given below. 
$ sudo adduser git
$ su git
$ cd
$ mkdir .ssh && chmod 700 .ssh
$ touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
  Let’s add some SSH keys to the authorized_keys file for the git user. They should be like 
$ cat /tmp/id_rsa.john.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCB007n/ww+ouN4gSLKssMxXnBOvf9LGt4L
ojG6rs6hPB09j9R/T17/x4lhJA0F3FR1rP6kYBRsWj2aThGw6HXLm9/5zytK6Ztg3RPKK+4k
Yjh6541NYsnEAZuXz0jTTyAUfrtU3Z5E003C4oxOj6H0rfIF1kKI9MAQLMdpGW1GYEIgS9Ez
Sdfd8AcCIicTDWbqLAcU4UpkaX8KyGlLwsNuuGztobF8m72ALC/nLF6JLtPofwFBlgc+myiv
O7TCUSBdLQlgMVOFq1I2uPWQOkOWQAHukEOmfjy2jctxSDBQ220ymjaNsHT4kgtZg2AYYgPq
dAv8JggJICUvax2T9va5 gsg-keypair
  We now append them to the git user’s authorized_keysfile in its .ssh directory. 
$ cat /tmp/id_rsa.john.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.josie.pub >> ~/.ssh/authorized_keys
$ cat /tmp/id_rsa.jessica.pub >> ~/.ssh/authorized_keys
  We can now set up an empty repository by running git init with the –bare option, which initializes a repository without a working directory. 
$ cd /srv/git
$ mkdir project.git
$ cd project.git
$ git init --bare
Initialized empty Git repository in /srv/git/project.git/
  Now one can push their first version of their project into that repository by adding it as a remote and pushing up a branch. We can now use a hostname of the server in which we have set up git user and repository. 
$ cd myproject
$ git init
$ git add .
$ git commit -m 'initial commit'
$ git remote add origin git@gitserver:/srv/git/project.git
$ git push origin master
  Now, others can clone the directory and push back the changes. 
$ git clone git@gitserver:/srv/git/project.git
$ cd project
$ vim README
$ git commit -am 'fix for the README file'
$ git push origin master
  We can restrict a user to have only git related activitis using a shell tool called git-shell. If we set the shell to a user’s login shell, he cannot have normal usage. To use, specify the git-shell instead of bash or csh for your user’s login shell.First add git-shell to /etc/shells if it does not exist. 
$ cat /etc/shells   # see if `git-shell` is already in there.  If not...
$ which git-shell   # make sure git-shell is installed on your system.
$ sudo vim /etc/shells  # and add the path to git-shell from last command
 
Now you can edit the shell for a user using chsh <username> -s <shell>: 
$ sudo chsh git -s $(which git-shell)
Now, the git user can only use the SSH connection to push and pull Git repositories and can’t shell onto the machine. If you try, you’ll see a login rejection like this. 
$ ssh git@gitserver
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.
Connection to gitserver closed.
  If you are in need of higher control over your git repositories, setup your own private git server.]]>

]]> Git – Resolving Conflicts /git-resolving-conflicts/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16372 ]]> git needs your help in deciding which change needs to be incorporated in the final merge of the branch.   Git can often resolve the difference between branches and merges the branches automatically. Usually, the changes are on different lines or even different files. This makes it easy for the computer to understand. However, there are few changes that git cannot resolve without the user’s help. This happens usually when different people make changes to the same line in a file or a person edits the file while another deletes it. This causes a conflict of changes while merging the branch.   We need to resolve all the conflicts before we merge a pull request to the git server. If we have a merge conflict between the compare branch and the base branch, we can see the files and the changes that caused the conflict above the merge pull request button. The merge pull request button is deactivated until the conflict is resolved.   To resolve the merge conflict, we need to manually edit the conflict inflicted changes. We must edit and specify the final changes that are to be merged. We can either resolve the changes in the local computer and then push to the repository or we can directly edit the changes in the conflict editor of the git server like github or gitlab. If we have any conflicts in the command line, we cannot push the local changes to the server until we resolve the merge conflicts. If we try to merge the branches with a conflict from the command line, we will be getting an error message. A sample error message is given below. 
git merge BRANCH-NAME
Auto-merging example.md
CONFLICT (content): Merge conflict in example.md
Automatic merge failed; fix conflicts and then commit the result
  Once the conflicts are resolved and the changes are pushed, be happy. You can now merge the branch with no worries.]]>

]]> Automate code formatting in your rails project /automate-code-formatting-in-your-rails-project/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16235 ]]> https://www.youtube.com/watch?v=C759shnD97k). The problem here is that we are all still human and we make mistakes, accidentally breaking the standard here or there. So we decided to automate this and finally have a devised a standard way to automate code formatting in our rails project. We will be automating both our ruby code and our JS code, since the marriage between web packer and rails it’s now inevitable to keep JS out of our workflow. The idea devised is to run the auto code check right after we commit the code, in case if there are any issues that can’t be auto-corrected by the system the system should stop the commit. Also, it’s important that the auto-correction runs only on the diff so that we don’t end up confusing the reviewers.   For a legacy project, I suggest doing `bundle exec rubocop –a` and fix the errors before adding this hook.  

How to implement

To implement this we are using husky (https://github.com/typicode/husky) a really nice JS library that helps us build git hooks easily. 
yarn add --dev husky
  The second JS library we are going to add is `lint-staged` which limits our formatters to only run on the staged git files (ie. The changes). 
yarn add --dev lint-staged
Once these two are installed we can set our system to autorun rubocop by adding the following lines to the package.json. 
"scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
   "{app,spec,lib}/**/*.rb": [
      "bundle exec rubocop -a",
      "git add"
    ]
  }
  the above configuration would ensure that our formatters run only inside the app or spec or lib folders. Also please note that since we have the pre commit hook, this code is executed after you typed `git commit –m` but it will get executed before the actual commit happening.  

Auto Formatting Javascript

https://prettier.io/ is an opinionated code formatter that supports many languages, in fact it’s also being extended to ruby. We will be using it to format our javascript code, which internally we are using es6. You can read more about it from its project page. 
yarn add --dev prettier
Following which we need to add to the script section of our code: 
   "app/**/*.{js,es6,jsx,scss,css}": [
      "./node_modules/prettier/bin-prettier.js --trailing-comma es5 --write",
      "git add"
    ]
The final package.json inside a fresh project would look like this: 
{
  "name": "starter",
  "private": true,
  "dependencies": {
    "@rails/webpacker": "^3.3.0"
  },
  "scripts": {
    "precommit": "lint-staged"
  },
  "lint-staged": {
    "app/**/*.{js,es6,jsx,scss,css}": [
      "./node_modules/prettier/bin-prettier.js --trailing-comma es5 --write",
      "git add"
    ],
    "{app,test}/**/*.rb": [
      "bundle exec rubocop -a",
      "git add"
    ]
  },
  "devDependencies": {
    "husky": "^0.13.4",
    "lint-staged": "^3.6.0",
    "prettier": "^1.4.2",
    "webpack-dev-server": "^2.11.1"
  }
}
 ]]>

]]> What is Test Driven Development? /what-is-test-driven-development/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16375 ]]> Test Driven Development (TDD) is a software development process that weighs on a short development cycle. The developer first writes an automated test defining the new feature or update, which fails at first, then write minimal code for the tests to pass, then refactor the code according to the needed standards. TDD is helpful in keeping the code neater, simple and bug-free   TDD starts with designing and developing tests for every small functionality of an application. The test is developed which will specify and validate what the code will do. n the normal Testing process, we first generate the code and then test. Tests might fail since tests are developed even before the development. In order to pass the test, the development team has to develop and refactors the code, which means changing the code without affecting its actual behaviour.   We usually follow the following sequences in TDD.
  • Add a test
  • Run all tests and see if the new one fails
  • Write some code
  • Run tests
  • Refactor code
  • Repeat
  The simple concept of TDD is to write and correct the failed tests before writing new code. This helps to avoid duplication of code as we write a small amount of code at a time in order to pass tests. Test-Driven development is a process of developing and running automated test before actual development of the application. Hence, TDD sometimes also called as Test First Development.   In short, TDD is
  1. Write a test
  2. Make it run.
  3. Change the code to make it right i.e. Refactor.
  4. Repeat process.
 

Why use Test Driven Development

  • Early bug notification.Developers test their code but in the database world, this often consists of manual tests or one-off scripts. Using TDD you build up, over time, a suite of automated tests that you and any other developer can rerun at will.
  • Better Designed, cleaner and more extensible code.
    • It helps to understand how the code will be used and how it interacts with other modules.
    • It results in better design decision and more maintainable code.
    • TDD allows writing smaller code having single responsibility rather than monolithic procedures with multiple responsibilities. This makes the code simpler to understand.
    • TDD also forces to write only production code to pass tests based on user requirements.
  • Confidence to Refactor
    • If you refactor code, there can be possibilities of breaks in the code. So having a set of automated tests you can fix those breaks before release. Proper warning will be given if breaks found when automated tests are used.
    • Using TDD, should results in faster, more extensible code with fewer bugs that can be updated with minimal risks.
  • Good for teamworkIn the absence of any team member, other team members can easily pick up and work on the code. It also aids knowledge sharing, thereby making the team more effective overall.
  • Good for DevelopersThough developers have to spend more time in writing TDD test cases, it takes a lot less time for debugging and developing new features. You will write cleaner, less complicated code.
  Test Driven Development is a very effective method to follow to keep our code, neat and bug-free.  ]]>

]]> History Of Git /history-of-git/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16347 ]]> ]]> Working Of Git /working-of-git/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16350 ]]> ]]> Git Blame /git-blame/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16352 ]]> Git, a version control software, is primarily used for source code management and tracking any changes any set of files. Git is very effective in coordinating the work of multiple people working on a project. Being a distributed revision control system, Git aims at speed, data integrity and support for distributed, non-linear workflows.

More than 1 developers may change the contents of a file. Using git blame, we can find the person responsible for the last change of code of each line. The command, as the name suggests, helps to find the person who changed a line of code and to blame them. In short, git blame shows the revision and author of each code of line of a file.

To get started with git blame, try the following syntax.

git blame filename
We then get the list of authors of each line of code for the file. git blame operates on individual files, therefore, it’s better to specify the path of the file. Here is a sample output of git blame. 
$ git blame README.md
82496ea3 (kev 2018-02-28 13:37:02 -0800 1) # Git Blame example
82496ea3 (kev 2018-02-28 13:37:02 -0800 2)
89feb84d (Alie So 2018-03-01 00:54:03 +0000 3) new line
82496ea3 (kev 2018-02-28 13:37:02 -0800 4)
82496ea3 (kev 2018-02-28 13:37:02 -0800 5) git blame
82496ea3 (kev 2018-02-28 13:37:02 -0800 6)
89feb84d (Alie So 2018-03-01 00:54:03 +0000 7) sun is going down

Commonly used options

We can use a set of options for git blame. Some of them are given below. 
git blame -L 1,5 README.md
This option restricts the display from lines 1 to 5.   
git blame -e README.md
This option displays the email address of the author instead of his username.   
git blame -w README.md
This option ignores the whitespaces in the file and mentions the authors of other lines.   
git blame -M README.md
This option detects the copied or moved lines within a file. The command returns the original author instead of the person who copied or moved the file.   
git blame -C README.md
This option detects the copied or moved lines among any files. The command returns the original author instead of the person who copied or moved the file.   git blame is a very useful command in finding the author of each line of code. and to see when the modifications were done. git blame comes in handy while managing a project.]]>

]]> Git Bisect /git-bisect/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16355 ]]> git bisect, we can find the bad commit much easier.   git bisect is a git command used to find the commit that introduced a bug in your code. We mention a  good commit where there was no bug and also a bad commit where we noticed the bug. git bisect picks a commit in between and asks if the commit is good or bad. This goes on till we find the bad commit. git bisect works just as a binary search does.   To get started with git bisect, we run the command 
git bisect start
Now, we add the good commit. The syntax is 
git bisect good commit_id
Then, we add the bad commit as the following syntax. 
git bisect bad commit_id
  Now, the command will trigger splitting the commits into half and revise it. We respond if the commit is good or bad as git bisect good or git bisect bad. The revision is narrowed down until we find the commit that caused the bug.   Sometimes, we can automate finding the bugs. We can pass any script and check the script against each commits. The commit returning a non-zero status is the failing one. Here, as an example, I am running a failing test 
git bisect run rspec spec/features/my_broken_spec.rb
  git bisect is an awesome method to find the commit which caused the bug. It helps us saving our time and money.  ]]>

]]> Git Rebase /git-rebase/ Mon, 29 Apr 2019 11:28:11 +0000 http://redpanthers.co/?p=16357 ]]> git rebase master or 
git rebase master feature_branch
  There are two ways to integrate the feature branch with the master, that is merging directly and rebasing and then merging. Merging directly results in a 3-way merge and has a merge commit. Rebasing and merging is a fast-forward merge and a perfect commit history.   Having a clean commit history is good, especially when it comes to finding bugs. Imagine a bug occurs in the code and the developer could not track where the bug was introduced using git log. Now, he may run git bisect to find the bad commit. Because the commit history is clean, the git bisect has a refined set of commits to work on. This helps the developer to find the bug faster.   We can run git rebase in an interactive mode by either giving the option -i or –interactive 
git rebase --interactive
This triggers the interactive mode. Interactive mode means we can play with the commits. Instead of the standard rebase, which moves all the commits blindly, the interactive commit let us alter with the commits. We can choose the commits we need, keeping the history cleaner. We can pick the commit, alter the commit, squash or discard the commit.   Rebasing is a very helpful way to integrate your branches while keeping your commit history clean, which helps while debugging.]]>

]]>