git ignore .gitignore file

In one of my project some of my changes in files should not be pushed to git.
In such case i came to know the command which does this

git update-index --assume-unchanged [(Files)]

For example i dont want push .gitignore file changes i did in my local . so command is

git update-index --assume-unchanged .gitignore

From git-update-index manual page:

--assume-unchanged
--no-assume-unchanged

When these flags are specified, the object names recorded for the paths are not updated. Instead, these options set and unset the “assume unchanged” bit for the paths.

When the “assume unchanged” bit is on, git stops checking the working tree files for possible modifications, so you need to manually unset the bit to tell git when you change the working tree file. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs).

get-nested-array-document-with-filter-mongo-db

Consider the Schema :

 "data": {
        "chapters": {
            "_id": "5b7c023bff64339c40613161",
            "courseworkId": "5b7c0228ff64339c40613160",
            "chapterName": "chapter1",
            "subChapters": [
                {
                    "questions": [
                        {
                     
                            "_id": "5b7c0a26ff64339c40613166",
                            "title": "test"
                        },
                        {
                            "_id": "5b7d046ee07f6e9ee72d0e38",
                            "title": "question 2"
                       
                        }
   ],
 "_id": "5b7c0446ff64339c40613162",
 "subChapterName": "subChapter9"
 }
}



GET sub document that match question ID : 5b7c0a26ff64339c40613166


1. Match the results for chapter Id
2. Go through the subchapters and see if we match the question Id and filter the results
db.chapter.aggregate([
  { "$match": {
    "_id" : ObjectId("5b7c023bff64339c40613161")
  }},         
  { "$addFields": {
    "subChapters": {
      "$filter": {
        "input": {
          "$map": {
            "input": "$subChapters",
            "as": "sc",
            "in": {
              "_id": "$$sc._id",
              "questions": {
                "$filter": {
                  "input": "$$sc.questions",
                  "as": "qu",
                  "cond": {
                      "$eq": [ "$$qu._id", ObjectId("5b7c0a26ff64339c40613166")  ]
                  }
                }
              }           
            }
          },
        },
        "as": "sc",
        "cond": {
          "$and": [
            { "$gt": [ { "$size": "$$sc.questions" }, 0 ] }
          ]
        }
      }
    }
  }}
])

git-merge-local-to-remote

git is basically nothing but pointers .

its just keep references to this pointers and play around with these branch and merge


So, when you want to merge your branch changes to your master .  you need to checkout to master
first and then do the merge of that branch.


> git branch <branch-name> 
           or
> git checkout -b <branch-name>

If you want to create a new branch to retain commits you create, you may

do so (now or later) by using -b with the checkout command again

> git add <some file > and git commit -m <somefile>

> git push origin <branch-name>

> git checkout master

> git merge <branch-name>

you may get conflicts . so , please try to resolve them and then push them to master or branch

> again git commit with removed conflicts -> Merge Success


Create local branch from remote and merge your changes.

> git checkout <origin/branchname>

> git checkout -b '<local branch name>'

> Do temporary changes or any commits to your local

> git checkout <origin/branchnam>

> git merge <localbranchname>

> git push origin <branchname>   ==> Merging to remote place .

git branch overview

* git branch -a

List down all the branch in the local and remote

* git branch -r

list down all the branch in remote



* git fetch --all

Fetches all the remote repos to local

* git checkout -b <branch name>

Checkout the branch name with current HEAD to the master.

Always do git fetch <remote> <branch> and git checkout -b <branch name> ==>


** git fetch + git merge (Safe to do instead git pull --> this is sometimes aggresive )==> git pull

Delete last git commit

Revert the full commit

Sometimes you may want to undo a whole commit with all changes. Instead of going through all the changes manually, you can simply tell git to revert a commit, which does not even have to be the last one. Reverting a commit means to create a new commit that undoes all changes that were made in the bad commit. Just like above, the bad commit remains there, but it no longer affects the the current master and any future commits on top of it.

git revert {commit_id}'

About History Rewriting

Delete the last commit

Deleting the last commit is the easiest case. Let's say we have a remote origin with branch master that currently points to commit dd61ab32. We want to remove the top commit. Translated to git terminology, we want to force the master branch of the origin remote repository to the parent of dd61ab32:

git push origin +dd61ab32^:master

Where git interprets x^ as the parent of x and + as a forced non-fastforward push. If you have the master branch checked out locally, you can also do it in two simpler steps: First reset the branch to the parent of the current commit, then force-push it to the remote.

git reset HEAD^ --hard

git push origin -f

git add / commit undo examples

 Undo add

               $ edit                                     (1)

               $ git add frotz.c filfre.c

               $ mailx                                    (2)

               $ git reset                                (3)

               $ git pull git://info.example.com/ nitfol  (4)

           1. You are happily working on something, and find the changes in

           these files are in good order. You do not want to see them when you

           run "git diff", because you plan to work on other files and changes

           with these files are distracting.

           2. Somebody asks you to pull, and the changes sound worthy of

           merging.

           3. However, you already dirtied the index (i.e. your index does not

           match the HEAD commit). But you know the pull you are going to make

           does not affect frotz.c or filfre.c, so you revert the index

           changes for these two files. Your changes in working tree remain

           there.

           4. Then you can pull and merge, leaving frotz.c and filfre.c

           changes still in the working tree.

       Undo a commit and redo

               $ git commit ...

               $ git reset --soft HEAD^      (1)

               $ edit                        (2)

               $ git commit -a -c ORIG_HEAD  (3)

           1. This is most often done when you remembered what you just

           committed is incomplete, or you misspelled your commit message, or

           both. Leaves working tree as it was before "reset".

           2. Make corrections to working tree files.

           3. "reset" copies the old head to .git/ORIG_HEAD; redo the commit

           by starting with its log message. If you do not need to edit the

           message further, you can give -C option instead.

           See also the --amend option to git-commit(1).

       Undo a commit, making it a topic branch

               $ git branch topic/wip     (1)

               $ git reset --hard HEAD~3  (2)

               $ git checkout topic/wip   (3)

           1. You have made some commits, but realize they were premature to

           be in the "master" branch. You want to continue polishing them in a

           topic branch, so create "topic/wip" branch off of the current HEAD.

           2. Rewind the master branch to get rid of those three commits.

           3. Switch to "topic/wip" branch and keep working.

  

 Undo commits permanently

               $ git commit ...

               $ git reset --hard HEAD~3   (1)

           1. The last three commits (HEAD, HEAD^, and HEAD~2) were bad and

           you do not want to ever see them again. Do not do this if you have

           already given these commits to somebody else. (See the "RECOVERING

           FROM UPSTREAM REBASE" section in git-rebase(1) for the implications

           of doing so.)

       Undo a merge or pull

               $ git pull                         (1)

               Auto-merging nitfol

               CONFLICT (content): Merge conflict in nitfol

               Automatic merge failed; fix conflicts and then commit the result.

               $ git reset --hard                 (2)

               $ git pull . topic/branch          (3)

               Updating from 41223... to 13134...

               Fast-forward

               $ git reset --hard ORIG_HEAD       (4)

           1. Try to update from the upstream resulted in a lot of conflicts;

           you were not ready to spend a lot of time merging right now, so you

           decide to do that later.

           2. "pull" has not made merge commit, so "git reset --hard" which is

           a synonym for "git reset --hard HEAD" clears the mess from the

           index file and the working tree.

           3. Merge a topic branch into the current branch, which resulted in

           a fast-forward.

           4. But you decided that the topic branch is not ready for public

           consumption yet. "pull" or "merge" always leaves the original tip

           of the current branch in ORIG_HEAD, so resetting hard to it brings

           your index file and the working tree back to that state, and resets

           the tip of the branch to that commit.

       Undo a merge or pull inside a dirty working tree

               $ git pull                         (1)

               Auto-merging nitfol

               Merge made by recursive.

                nitfol                |   20 +++++----

                ...

               $ git reset --merge ORIG_HEAD      (2)

           1. Even if you may have local modifications in your working tree,

           you can safely say "git pull" when you know that the change in the

           other branch does not overlap with them.

           2. After inspecting the result of the merge, you may find that the

           change in the other branch is unsatisfactory. Running "git reset

           --hard ORIG_HEAD" will let you go back to where you were, but it

           will discard your local changes, which you do not want. "git reset

           --merge" keeps your local changes.

 Interrupted workflow

           Suppose you are interrupted by an urgent fix request while you are

           in the middle of a large change. The files in your working tree are

           not in any shape to be committed yet, but you need to get to the

           other branch for a quick bugfix.

               $ git checkout feature ;# you were working in "feature" branch and

               $ work work work       ;# got interrupted

               $ git commit -a -m "snapshot WIP"                 (1)

               $ git checkout master

               $ fix fix fix

               $ git commit ;# commit with real log

               $ git checkout feature

               $ git reset --soft HEAD^ ;# go back to WIP state  (2)

               $ git reset                                       (3)

           1. This commit will get blown away so a throw-away log message is

           OK.

           2. This removes the WIP commit from the commit history, and sets

           your working tree to the state just before you made that snapshot.

           3. At this point the index file still has all the WIP changes you

           committed as snapshot WIP. This updates the index to show your WIP

           files as uncommitted.

           See also git-stash(1).

       Reset a single file in the index

           Suppose you have added a file to your index, but later decide you

           do not want to add it to your commit. You can remove the file from

           the index while keeping your changes with git reset.

               $ git reset -- frotz.c                      (1)

               $ git commit -m "Commit files in index"     (2)

               $ git add frotz.c                           (3)

           1. This removes the file from the index while keeping it in the

           working directory.

           2. This commits all other changes in the index.

           3. Adds the file to the index again.

       Keep changes in working tree while discarding some previous commits

           Suppose you are working on something and you commit it, and then

           you continue working a bit more, but now you think that what you

           have in your working tree should be in another branch that has

           nothing to do with what you committed previously. You can start a

           new branch and reset it while keeping the changes in your working

           tree.

               $ git tag start

               $ git checkout -b branch1

               $ edit

               $ git commit ...                            (1)

               $ edit

               $ git checkout -b branch2                   (2)

               $ git reset --keep start                    (3)

           1. This commits your first edits in branch1.

           2. In the ideal world, you could have realized that the earlier

           commit did not belong to the new topic when you created and

           switched to branch2 (i.e. "git checkout -b branch2 start"), but

           nobody is perfect.

           3. But you can use "reset --keep" to remove the unwanted commit

           after you switched to "branch2".

       Split a commit apart into a sequence of commits

           Suppose that you have created lots of logically separate changes

           and committed them together. Then, later you decide that it might

           be better to have each logical chunk associated with its own

           commit. You can use git reset to rewind history without changing

           the contents of your local files, and then successively use git add

           -p to interactively select which hunks to include into each commit,

           using git commit -c to pre-populate the commit message.

               $ git reset -N HEAD^                        (1)

               $ git add -p                                (2)

               $ git diff --cached                         (3)

               $ git commit -c HEAD@{1}                    (4)

               ...                                         (5)

               $ git add ...                               (6)

               $ git diff --cached                         (7)

               $ git commit ...                            (8)

           1. First, reset the history back one commit so that we remove the

           original commit, but leave the working tree with all the changes.

           The -N ensures that any new files added with HEAD are still marked

           so that git add -p will find them.

           2. Next, we interactively select diff hunks to add using the git

           add -p facility. This will ask you about each diff hunk in sequence

           and you can use simple commands such as "yes, include this", "No

           don't include this" or even the very powerful "edit" facility.

           3. Once satisfied with the hunks you want to include, you should

           verify what has been prepared for the first commit by using git

           diff --cached. This shows all the changes that have been moved into

           the index and are about to be committed.

           4. Next, commit the changes stored in the index. The -c option

           specifies to pre-populate the commit message from the original

           message that you started is a special notation for the commit that

           HEAD used to be at prior to the original reset commit (1 change

           ago). See git-reflog(1) for more details. You may also use any

 ago). See git-reflog(1) for more details. You may also use any

           other valid commit reference.

           5. You can repeat steps 2-4 multiple times to break the original

           code into any number of commits.

           6. Now you've split out many of the changes into their own commits,

           and might no longer use the patch mode of git add, in order to

           select all remaining uncommitted changes.

           7. Once again, check to verify that you've included what you want

           to. You may also wish to verify that git diff doesn't show any

           remaining changes to be committed later.

           8. And finally create the final commit.

DISCUSSION

       The tables below show what happens when running:

           git reset --option target

       to reset the HEAD to another commit (target) with the different reset

       options depending on the state of the files.

       In these tables, A, B, C and D are some different states of a file. For

       example, the first line of the first table means that if a file is in

       state A in the working tree, in state B in the index, in state C in

       HEAD and in state D in the target, then "git reset --soft target" will

       leave the file in the working tree in state A and in the index in state

       B. It resets (i.e. moves) the HEAD (i.e. the tip of the current branch,

       if you are on one) to "target" (which has the file in state D).

           working index HEAD target         working index HEAD

           ----------------------------------------------------

            A       B     C    D     --soft              A       B     D

                                            --mixed          A       D     D

                                            --hard             D       D     D

                                           --merge         ( disallowed)

                                          --keep              (disallowed)

           working index HEAD target         working index HEAD

           ----------------------------------------------------

            A       B     C    C     --soft   A       B     C

                                     --mixed  A       C     C

                                     --hard   C       C     C

                                     --merge (disallowed)

                                     --keep   A       C     C

           working index HEAD target         working index HEAD

           ----------------------------------------------------

            B       B     C    D     --soft   B       B     D

                                     --mixed  B       D     D

                                     --hard   D       D     D

                                     --merge  D       D     D

                                     --keep  (disallowed)

           working index HEAD target         working index HEAD

            ----------------------------------------------------

            B       B     C    C     --soft   B       B     C

                                     --mixed  B       C     C

                                     --hard   C       C     C

                                     --merge  C       C     C

                                     --keep   B       C     C

           working index HEAD target         working index HEAD

           ----------------------------------------------------

            B       C     C    D     --soft   B       C     D

                                     --mixed  B       D     D

                                     --hard   D       D     D

                                     --merge (disallowed)

                                     --keep  (disallowed)

           working index HEAD target         working index HEAD

           ----------------------------------------------------

            B       C     C    C     --soft   B       C     C

                                     --mixed  B       C     C

                                     --hard   C       C     C

                                     --merge  B       C     C

                                     --keep   B       C     C

       "reset --merge" is meant to be used when resetting out of a conflicted

       merge. Any mergy operation guarantees that the working tree file that

       is involved in the merge does not have local change wrt the index

       before it starts, and that it writes the result out to the working

       tree. So if we see some difference between the index and the target and

       also between the index and the working tree, then it means that we are

       not resetting out from a state that a mergy operation left after

       failing with a conflict. That is why we disallow --merge option in this

       case.

       "reset --keep" is meant to be used when removing some of the last

       commits in the current branch while keeping changes in the working

       tree. If there could be conflicts between the changes in the commit we

       want to remove and the changes in the working tree we want to keep, the

       reset is disallowed. That's why it is disallowed if there are both

       changes between the working tree and HEAD, and between HEAD and the

       target. To be safe, it is also disallowed when there are unmerged

       entries.

       The following tables show what happens when there are unmerged entries:

           working index HEAD target         working index HEAD

           ----------------------------------------------------

            X       U     A    B     --soft  (disallowed)

                                     --mixed  X       B     B

                                     --hard   B       B     B

                                     --merge  B       B     B

                                     --keep  (disallowed)

           working index HEAD target         working index HEAD

           ----------------------------------------------------

            X       U     A    A     --soft  (disallowed)

                                     --mixed  X       A     A

                                     --hard   A       A     A

                                     --merge  A       A     A

                                     --keep  (disallowed)

       X means any state and U means an unmerged index.

git integrator tips

INTEGRATOR

       A fairly central person acting as the integrator in a group project

       receives changes made by others, reviews and integrates them and

       publishes the result for others to use, using these commands in

       addition to the ones needed by participants.

       This section can also be used by those who respond to git request-pull

       or pull-request on GitHub (www.github.com) to integrate the work of

       others into their history. An sub-area lieutenant for a repository will

       act both as a participant and as an integrator.

       o   git-am(1) to apply patches e-mailed in from your contributors.

       o   git-pull(1) to merge from your trusted lieutenants.

       o   git-format-patch(1) to prepare and send suggested alternative to

           contributors.

       o   git-revert(1) to undo botched commits.

       o   git-push(1) to publish the bleeding edge.

   Examples

       A typical integrator's Git day.

               $ git status (1)

               $ git branch --no-merged master (2)

               $ mailx (3)

               & s 2 3 4 5 ./+to-apply

               & s 7 8 ./+hold-linus

               & q

               $ git checkout -b topic/one master

               $ git am -3 -i -s ./+to-apply (4)

               $ compile/test

               $ git checkout -b hold/linus && git am -3 -i -s ./+hold-linus (5)

               $ git checkout topic/one && git rebase master (6)

               $ git checkout pu && git reset --hard next (7)

               $ git merge topic/one topic/two && git merge hold/linus (8)

               $ git checkout maint

               $ git cherry-pick master~4 (9)

               $ compile/test

               $ git tag -s -m "GIT 0.99.9x" v0.99.9x (10)

               $ git fetch ko && for branch in master maint next pu (11)

                   do

                       git show-branch ko/$branch $branch (12)

                   done

               $ git push --follow-tags ko (13)

           1. see what you were in the middle of doing, if anything.

           2. see which branches haven't been merged into master yet. Likewise

           for any other integration branches e.g.  maint, next and pu

           (potential updates).

(potential updates).

           3. read mails, save ones that are applicable, and save others that

           are not quite ready (other mail readers are available).

           4. apply them, interactively, with your sign-offs.

           5. create topic branch as needed and apply, again with sign-offs.

           6. rebase internal topic branch that has not been merged to the

           master or exposed as a part of a stable branch.

           7. restart pu every time from the next.

           8. and bundle topic branches still cooking.

           9. backport a critical fix.

           10. create a signed tag.

           11. make sure master was not accidentally rewound beyond that

           already pushed out.

           12. In the output from git show-branch, master should have

           everything ko/master has, and next should have everything ko/next

           has, etc.

           13. push out the bleeding edge, together with new tags that point

           into the pushed history.

       In this example, the ko shorthand points at the Git maintainer's

       repository at kernel.org, and looks like this:

           (in .git/config)

           [remote "ko"]

                   url = kernel.org:/pub/scm/git/git.git

                   fetch = refs/heads/*:refs/remotes/ko/*

                   push = refs/heads/master

                   push = refs/heads/next

                   push = +refs/heads/pu

                   push = refs/heads/maint