A noob method of playing with Node modules

Steps to follow to update code from a node_module like d3-force directly !!

So what we get in a node_modules are the build folder that dont support HRM (hot reload module) so we have to make changes and then build that folder using the rollup module ( maybe we can use other libs also !!)

Steps:

  1. Make that change in the file that you want !!(be it debugging statements or logic change )
  2. Install the required files, using npm install and if required change the package manager from yarn to npm
  3. Then lookup to package.json and you might find a function named “prepublishOnly”
  4. Run the command npm run prepublishOnly, If the command requires the some folder , build those or remove those folders from the npm command !!
  5. Then once you fix the errors , got the errors solved , then we build this file using npm run prepublishOnly
  6. Then run the development server using the npm run dev -- --cache

This is how to rebuild a node-module !!

Github commands

Checkout to a branch that is available on remote and not on local

ggiittcbhreacnkcohut--sbetb-ruapnscthr_enaamm-eto=origin/branch_name

better method for same,

gitcheckout-bbranch_nameorigin/branch_name

Check the status remote of this branch

git status -sb

Pull ⚠️

Pulls the changes from remote branches to your local branches (use carefully can be destructive)

git pull origin : Pulls changes from same remote branch. eg: If on branch feat1 this command pulls from origin/feat1

On the other side we can also do

git pull origin/main: Pulls changes from origin/main. eg: If on branch feat1 this command pulls from origin/main and this can lead to conflicts as well

So we define a pull strategy and we have 2 options to choose from :

git config pull.rebase false: makes the default git behaviour as pull and merge (your commit history is not maintained in this) git config pull.rebase true : pulls the latest commits to the branch and add your commits on top of that

Before :

M---N-A----X--B----Y-C(oyroiugrinl/omcaailn)main)

After rebase :

M---N---A---B---C---X---Y(yourlocalmain)

this takes changes from origin first and then on top add our changes over it

Rebase false

M---N-mA-e--r-Xg--eB-↑--c-Yo--mC-m-iMt'←yourbranchnow

Dropping specific files changes

gggiiittttccchhhoeeemnccmkkirootauuitt-smemoyr"a-iDbgrPrioRanpn/fcmuohanrirneiltattbheuipdtsatcrihhes/amtnetogmh/ebeusen"rowraiinngtiecdndeamvlfmiiybltoreuastnncehtehditenatkoowerhiritgechivhenesarweltefbbniraelaceenkdschttfoorotmmhaektehpertohoderiocgnhieann/fgmoearsinthbirsanch

Problem when working in a large team where many are working on same features

Problems:

  1. many people working on same file, potential conflict
  2. you working on a seperate feature , others working on other features
  3. you deployed branch on prod and then rebased the branch, that leads to fast-forward errors cause remote feat branch doesnt know about these rebased commits

Rebase :

Lifts your local commits off the branch and puts them in a temporary “holding area.”
Resets your branch to match the latest commit on the branch from where you are rebasing e.g. : (feature) git rebase origin/main , here first we will have changes from origin/main and then we get changes from feature branch on top of this.

Replays your commits one by one on top of that new base branch

Industry standard is to first do rebase, fix errors that come in between and jsut stage those dont commit , and continue your replay using this command : git rebase --continue that and then do squash and merge, else if no conflict comes then change this part

Rebase , Squash and Merge and then Rebase : deadly , first you rebased (nice) , then did squash and merge ( nice , and now a new commit was created that your feature branch has no idea of and then you try to do rebase ( git tries to rerun your commits over top of the new commit and results in massive conflicts ) so you start getting merge conflicts in that part.

Once a branch is squashed , retire that branch dont use that same branch again

Sometimes rebase gives issues that is it gets a merge conflict then you need to continue it : git rebase --continue

and if you want that these changes / resolution get resolved git config --global rerere.enabled true or git config rerere.enabled true

Merge:

Keeps the commits seperately so that everything can be known like when was this started , its first commit and helps in keeping all the history --no-commit : stages all the commit but doesnt create that final merge commit.
simple merge : merges the branch and adds that final merge commit as well to it.

BEST METHOD :

MWT23TFahh..henyeeayttWDDRumhoeeeroervvsedykuefRSlArpleqtnrobu:aewaadtf:ssTdeeehhecr1s-edh.Milemctorao:DcgimeaenFpWvlseahlbanewyirtinonauerttnrshkooceush(nsmBtdotalhrnaioaieynodnda.kdksusefpdGoelofatiotokgduelerdBeveaau,etgl(ecMo5.lCep0eteafarmni,se,xseaaspdnryr.deocfhpoeiumsgsmshhii-itognsnrg)ao.lwctolhdiessttdaaoriftluyfp,esa)atup"rrNeeosfr:emralSqMuearsghe"anmdakMeesrgteh.emainbranchhistoryimpossibletoread.Itbecomesajungleoftiny,meaninglesscommits.

To solve problem 3, we need to push but with lease so use : git push --force-with-lease , this makes sure to push changes only if no one else has pushed in your branch in that time

Stashing

Using stash you save your current changes and then go back to some other branch and pop those changes there

stash push : git stash push -m '<message>' , pushes into stash stash pop : git stash pop , removes it from stash stash apply : git stash apply stash@{0/1/2/..} , does not remove the stash stash list : git stash list stash drop : git stash drop stash@{0/1/2/..} , deletes a stash manually stash clear : git stash clear , deletes everything stash untracked files as well : git stash -u stash parts of a file : git stash -p , not useful

Reseting changes

Very helpful feature, lets say you commited some files and made 10 commits on top of main and now you need to merge those changes on main and there you realized that some files are not in correct shape like you wanted so there this reset comes in handy

git reset --soft <commit-id> : this takes all file changes that you had above this commit-id in the staged changes place and then we can compare and see that with the other branch and get to know what all changes you did in all those commits

never do git reset --hard <commit-id>

Orphan branch

So if you need to create a branch in a repo and you dont need historical commits and baggage from it, the best way to start this a clean repo with all changes in staged is to do git checkout --orphan <branch-name>

Tracked / untracked files

So something you need to keep files that are branch specific in that case you can either add that to your gitignore or you can remove that from tracking area

So if the file is already untracked, then its very simple just add that file in .gitignore and if that file is already tracked then you need to stop tracking it : git rm --cached <file>

Pushing code to remote

Wherever your local commits are different from the origin one you need to push it (soft or hard push)

so soft push are something that are over / addition to the commits that are already present in remote and these are easily pushed and requires no more changes over top.
git push

Hard push, if the commit history is different in local and remote there we need to use this hard push and possible hard push are : git push --force-with-lease and