what is rebase

Author: rohan-paul

Git-and-Github/delete-a-commit-from-Github.md

@@ -6,7 +6,7 @@ And there I somehow made 2 commits, and pushed them.
 
 After going back to source branch, subsequent rake gen_deploy will give this error:
 
-``failed to push some refs to 'git@github.com:samwize/samwize.github.com'``
+`failed to push some refs to 'git@github.com:samwize/samwize.github.com'`
 
 I don’t really understand why.
 
@@ -16,15 +16,15 @@ But I knew I shouldn’t push the 2 commits in the first place.
 
 Firstly, find out the comit that you want to revert back to.
 
-``git log``
+`git log`
 
 For example, commit 7f6d03 was before the 2 wrongful commits.
 
-press q to exit from ``git log``
+press q to exit from `git log`
 
 Force push that commit as the new master:
 
-``git push origin +7f6d03:master``
+`git push origin +7f6d03:master`
 
 ### The + is interpreted as forced push.
 
@@ -38,9 +38,6 @@ You can also use git reset to undo things. Then force push.
 
 Source - [https://samwize.com/2014/01/15/how-to-remove-a-commit-that-is-already-pushed-to-github/](https://samwize.com/2014/01/15/how-to-remove-a-commit-that-is-already-pushed-to-github/)
 
-
-
-
 ## To delete a commit from Github - my earlier note, but should work still now
 
 https://stackoverflow.com/questions/10817906/delete-a-commit-from-github?lq=1
@@ -49,20 +46,18 @@ https://stackoverflow.com/questions/10817906/delete-a-commit-from-github?lq=1
 git reset --hard <sha-commit-name-to-go-back-to>
 
 git push -f origin HEAD^:master
-
 ```
 
-In first command for "**sha-commit-name-to-go-back-to**"  - I copied-and-pasted, the the SHA Key (click on the that specific commit, and then on the right side of the page).
+In first command for "**sha-commit-name-to-go-back-to**" - I copied-and-pasted, the the SHA Key (click on the that specific commit, and then on the right side of the page).
 
 This commit was named as “second commit” and after the above 2 commands the entire commit and also another commit (named “third commit”) was deleted. Meaning, the above 2 commands will delete all commits starting from the SHA Key and any forward commit.
 
 But then, when I added the correct version of the full project (by following the above 3 steps) – all the previous commit came right back.
 
 Have to study in moer detail (as of 26-May-2014) to get the correct solution be able to delete a single commit only.
 
-
 Specially Note, as per the above link, when I ran the below 2 commands
 
-``git rebase -i HEAD~2``  and then ``git push origin +master`` after running the above 2, my Project got completely messed up and went back to much backwards state.
+`git rebase -i HEAD~2` and then `git push origin +master` after running the above 2, my Project got completely messed up and went back to much previous state.
 
-### The + is interpreted as forced push.
+### The + is interpreted as forced push.

Git-and-Github/git-merge.png

@@ -0,0 +1,59 @@
+In Git, there are two main ways to integrate changes from one branch into another: the merge and the rebase
+
+Git’s rebase command reapplies your changes onto another branch. As opposed to merging, which pulls the differences from the other branch into yours, rebasing switches your branch’s base to the other branch’s position and walks through your commits one by one to apply them again.
+
+Let’s look at an example. While working on a branch named login, based on the master branch, one of your team members pushed some changes to master. You need these changes to finish the login feature in your branch.
+
+Merging the master branch back into yours would result in a merge commit, which includes the changes between both branches and exists to show where a merge occured. We won’t need to know when we merged the master into the login branch in the future. Instead, we’d like to pretend that all commits on the login branch happened based on the new state of the master branch.
+
+<img src="git-rebase.png">
+
+Git’s rebase command temporarily rewinds the commits on your current branch, pulls in the commits from the other branch and reapplies the rewinded commits back on top. By switching the current This bases the current branch onto the other branch.
+
+`$ git rebase master`
+
+It’s as if you didn’t start working in the login branch before the commits you pulled in were made. You can also pull with rebase so you don’t have to switch out of your current branch.
+
+## More Explanation
+
+How the `git merge` works - It performs a three-way merge between the two latest branch snapshots (C3 and C4) and the most recent common ancestor of the two (C2), creating a new snapshot (and commit).
+
+<img src="git-merge.png">
+
+However in `git rebase` you can take the patch of the change that was introduced in C4 and reapply it on top of C3. In Git, this is called rebasing. With the rebase command, you can take all the changes that were committed on one branch and replay them on another one.
+
+In this example, you’d run the following:
+
+```js
+$ git checkout experiment
+$ git rebase master
+First, rewinding head to replay your work on top of it...
+Applying: added staged command
+```
+
+### It works by going to the common ancestor of the two branches (the one you’re on and the one you’re rebasing onto), getting the diff introduced by each commit of the branch you’re on, saving those diffs to temporary files, resetting the current branch to the same commit as the branch you are rebasing onto, and finally applying each change in turn.
+
+<img src="git-rebase-2.png">
+
+At this point, you can go back to the master branch and do a fast-forward merge.
+
+```js
+$ git checkout master
+$ git merge experiment
+```
+
+<img src="git-rebase-2.png">
+
+#### Now, the snapshot pointed to by C4' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. If you examine the log of a rebased branch, it looks like a linear history: it appears that all the work happened in series, even when it originally happened in parallel.
+
+Often, you’ll do this to make sure your commits apply cleanly on a remote branch — perhaps in a project to which you’re trying to contribute but that you don’t maintain. In this case, you’d do your work in a branch and then rebase your work onto origin/master when you were ready to submit your patches to the main project. That way, the maintainer doesn’t have to do any integration work — just a fast-forward or a clean apply.
+
+#### Note that the snapshot pointed to by the final commit you end up with, whether it’s the last of the rebased commits for a rebase or the final merge commit after a merge, is the same snapshot – it’s only the history that is different. Rebasing replays changes from one line of work onto another in the order they were introduced, whereas merging takes the endpoints and merges them together.
+
+### Additional Resources
+
+[https://jeffkreeftmeijer.com/git-rebase/](https://jeffkreeftmeijer.com/git-rebase/)
+
+[https://git-scm.com/book/en/v2/Git-Branching-Rebasing](https://git-scm.com/book/en/v2/Git-Branching-Rebasing)
+
+[https://blog.algolia.com/master-git-rebase/](https://blog.algolia.com/master-git-rebase/)

Git-and-Github/git-rebase-2.png

@@ -0,0 +1,23 @@
+### How GridFS works and why we would need this
+
+Mongodb provides us with a very efficient way to store files directly in db rather than in file system. So basically what this means is, suppose you need to store an image file or an audio or video file you can directly store that in mongodb itself.
+
+However, MongoDB is a NoSQL document-database, meaning it stores the data in the form of documents. Default document size limit in MongoDB is 16MB. That is if you want to store files upto 16MB then it’s not a big deal. But to store heavy files of size exceeding 16MB, MongoDB provides a module called GridFS. What GridFS does is that it divides your files into the chunks of 255kB (initially it was 256kB) and then stores it into the database.
+
+What exactly happens is it creates two collections in your database instance that you are currently using. In one collection, it stores the 255kB chunks of the files and the other collection is a document that contains the meta-data of your file.
+
+[Official document page](https://docs.mongodb.com/manual/core/gridfs/)
+
+To use with GridFS and multer for file upload functionality, two other very important packages we would use are `multer-gridfs-storage` and `gridfs-stream` like so.
+
+```
+const GridFsStorage = require('multer-gridfs-storage');
+
+const Grid = require('gridfs-stream');
+```
+
+Why multer-gridfs-storage - https://github.com/devconcept/multer-gridfs-storage/wiki/Using-generator-functions - GridFS storage engine for Multer to store uploaded files directly to MongoDb.
+
+gridfs-stream is required for streaming files to and from MongoDB GridFS.
+
+The gridfs-stream module exports a constructor that accepts an open mongodb-native db and the mongodb-native driver you are using. The db must already be opened before calling **createWriteStream** or **createReadStream**.

Git-and-Github/git-rebase-3.png

@@ -5,19 +5,18 @@ Say my user scheme is as below
 ```js
 var UserSchema = new Schema({
   username: {
-        type: String,
-        unique: true,
-        required: true
-    },
+    type: String,
+    unique: true,
+    required: true
+  },
   password: {
-        type: String,
-        required: true
-    }
+    type: String,
+    required: true
+  }
 });
-
 ```
 
-And running ``db.users.find().pretty()`` gives me the below result in terminal
+And running `db.users.find().pretty()` gives me the below result in terminal
 
 ```
 {
@@ -32,10 +31,9 @@ And running ``db.users.find().pretty()`` gives me the below result in terminal
 	"password" : "$2a$10$HyXCD5.4U/0CvZHq9SDQ0uxD12BQ46yVAHu18lRRVEQZB3uyHXgy.",
 	"__v" : 0
 }
-
 ```
 
-### Now use ``db.users.insert`` to add a new document (i.e. record ) into this users collection run the below in terminal
+### Now use `db.users.insert` to add a new document (i.e. record ) into this users collection run the below in terminal
 
 ```
 db.users.insert(
@@ -47,8 +45,8 @@ db.users.insert(
 )
 ```
 
-#### Note, I dont have to provide a separate _id field as mongodb will generate that by itself
+#### Note, I dont have to provide a separate \_id field as mongodb will generate that by itself
 
 And the part "$2a$10$HyXCD5.4U/0CvZHq9SDQ0uxD12BQ46yVAHu18lRRVEQZB3uyHXgy." is what I generated a hashed version of a plaintext password using the online tool [https://bcrypt-generator.com/](https://bcrypt-generator.com/) . Because in my actual app (where this was implemented) I used bcrypt to hash the password.
 
-But I could very well used "123"  in the mongo shell.
+But I could very well used "123" in the mongo shell.

Git-and-Github/git-rebase.md

@@ -4,36 +4,34 @@
 
 Take an example of a social-network [https://github.com/PrinceDavis/mongodb-joins](https://github.com/PrinceDavis/mongodb-joins). The repo contains a working webservice that allow you to create users, posts, and comments. You can also fetch users, their friends, posts, post creators and comments.
 
-Here's my user model - ``src/models/user/user.js``
+Here's my user model - `src/models/user/user.js`
 
 ```js
 const Schema = new mongoose.Schema({
   fullname: {
-      type: String,
-      required: true
-      },
+    type: String,
+    required: true
+  },
   username: {
-      type: String,
-      required: true
-      },
+    type: String,
+    required: true
+  },
   friends: [
-        {
-        type: mongoose.Schema.ObjectId,
-        ref: 'User'
-        }
+    {
+      type: mongoose.Schema.ObjectId,
+      ref: "User"
+    }
   ]
-})
-
-module.exports = mongoose.model('User', Schema)
+});
 
+module.exports = mongoose.model("User", Schema);
 ```
 
 Here I created a mongoose schema for user data, notice that the type of friends is itself a type of ObjectId and has a ref property, this is how mongoose perform collection linking or join or relationships. Each user would have a friends array which would hold id values of other friends that they are friends with. back in the all method in our controller where we call populate function on UserModel we are telling mongoose to swap the id values for the real collection that those values represent.
 
-
 #### And then in my src/models/post/post.js
 
-A post has comment and a user who created it. That is, a Post belong to a User, hence it's 'creator' property will have its ref to ``User``
+A post has comment and a user who created it. That is, a Post belong to a User, hence it's 'creator' property will have its ref to `User`
 
 ```js
 const Schema = new mongoose.Schema({
@@ -44,15 +42,16 @@ const Schema = new mongoose.Schema({
 
 module.exports = mongoose.model('Post', Schema)
 ```
-### And this is my comment.js file. A comment belog to a Post, hence the 'post' property will have its ref to ``Post``
+
+### And this is my comment.js file. A comment belog to a Post, hence the 'post' property will have its ref to `Post`
 
 ```js
 const Schema = new mongoose.Schema({
-  post: { type: mongoose.Schema.ObjectId, ref: 'Post' },
+  post: { type: mongoose.Schema.ObjectId, ref: "Post" },
   body: { type: String, required: true }
-})
+});
 
-module.exports = mongoose.model('Comment', Schema)
+module.exports = mongoose.model("Comment", Schema);
 ```
 
 #### The ref attribute
@@ -61,19 +60,16 @@ DBRefs have the following fields:
 
 $ref - The $ref field holds the name of the collection where the referenced document resides.
 
-$id - The $id field contains the value of the _id field in the referenced document.
+$id - The $id field contains the value of the \_id field in the referenced document.
 
 $db - Optional.
 
 Contains the name of the database where the referenced document resides.
 
 Only some drivers support $db references.
 
-
-
 https://docs.mongodb.com/manual/reference/database-references/#dbrefs
 
-
 ### More sources to read about
 
-[https://docs.mongodb.com/manual/reference/database-references/](https://docs.mongodb.com/manual/reference/database-references/)
+[https://docs.mongodb.com/manual/reference/database-references/](https://docs.mongodb.com/manual/reference/database-references/)

Git-and-Github/git-rebase.png

@@ -1,6 +1,6 @@
 https://redux.js.org/api-reference/store#dispatch
 
-dispatch() is one of the 4 methods of redux-store. dispatch() is the method used to dispatch actions and trigger state changes to the store. ``react-redux`` is simply trying to give you convenient access to it.
+dispatch() is one of the 4 methods of redux-store. dispatch() is the method used to dispatch actions and trigger state changes to the store. `react-redux` is simply trying to give you convenient access to it. So the way we take `actions` to the `store` is `dispatch`
 
 ```
 ​getState()​
@@ -11,6 +11,7 @@ dispatch() is one of the 4 methods of redux-store. dispatch() is the method used
 
 ​replaceReducer(nextReducer)​
 ```
+
 ## dispatch(action)​
 
 Dispatches an action. This is the only way to trigger a state change.
@@ -24,9 +25,10 @@ Returns
 (Object): The dispatched action (see notes).
 
 ## Object serialization
+
 Object serialization is the process of converting an object’s state to a string from which it can later be restored. ECMAScript 5 provides native functions JSON.stringify() and JSON.parse() to serialize and restore JavaScript objects. These functions use the JSON data interchange format.
 
-## My working example - ../brad-mern-shopping-list/client/src/actions/itemActions.js
+## My working example - ../brad-mern-shopping-list-Redux-No-Edit-Functionality/client/src/actions/itemActions.js
 
 ```js
 import axios from 'axios';
@@ -51,12 +53,12 @@ export const setItemsLoading = item => {
         type: ITEMS_LOADING
     }
 }
-
 ```
+
 I am using dispatch() to send the type along with the data that we get from the axios request to the backend. The main function (addItem) dispatches another function ( setItemsLoading ). This second function is called a thunk, and it returns the object/action. In the context of redux-thunk, a thunk is a second function that performs delayed logic by being asynchronously returned by a first function.
 
 This double function strategy allows us to wait for an asynchronous operation (like fetching data) to complete, and then the action is returned by the thunk.
 
 The plain data flows in a typical Redux is like this >> dispatch(action) -> reducer -> new state -> re-render
 
-The adjusted order, including reducers, is: dispatch ➡️ action creator ➡️ thunk ➡️ action ➡️ reducer.
+The adjusted order, including reducers, is: dispatch ➡️ action creator ➡️ thunk ➡️ action ➡️ reducer.