I'm writing down some of the things I've picked up when I started to learn about Node, Express and Mongo. Here are all the post in the series:
I'm using git for source control. That statement is more a less a given these days. Ha - long gone are the days when this was a war. Git won and since I host my stuff on GitHub too it's even more compelling.
I've already written about my small, but to me sufficient knowledge about git, but I dare to repeat it here. I have actually got by the last 3 years with just knowing 6-7 commands and understanding some simple facts about the git architecture.
Git is a distributed source control system, meaning that every developer have a complete copy of the repository. You clone the repository to get a local copy, of your own. In addition Git uses a staging area in which you "compose" a commit before you commit it into the repository. This concept is vital to understand and not be confused by the git-way.
Speaking of the git-way... there are graphical tools. I don't use them. The terminal makes me understand git much better and the visualisations are often making me confused.
Here are all the commands I know and use:
The only thing I often need to look up is when you start locally and then want to push it to a remote, like GitHub. Often I create an empty repository at GitHub (great wizard to do that at GitHub) and then git clone that URL. But when I haven't... I'm at a loss. So for me only; this is a workflow for to start locally and then push to GitHub (or another remote).
First start as normal locally:
I hope you found this useful. I know that I will. This kind of knowledge is what's fall out of my head quickly if I don't use it.
- Doing stuff in the terminal is not scary at all
- npm is not only for getting packages
- Package.json is a mighty tool
- Git is not that hard, but I need to refresh my knowledge - this post
- Callback function is cool stuff, and I even know how to write them
- mocha is cool both as framework and test runner
- Should is a nice way to do asserts
- monk is an easy way to access mongo
- Express is best without generators
- supertest is a nice way to test an api
I'm using git for source control. That statement is more a less a given these days. Ha - long gone are the days when this was a war. Git won and since I host my stuff on GitHub too it's even more compelling.
I've already written about my small, but to me sufficient knowledge about git, but I dare to repeat it here. I have actually got by the last 3 years with just knowing 6-7 commands and understanding some simple facts about the git architecture.
Git is a distributed source control system, meaning that every developer have a complete copy of the repository. You clone the repository to get a local copy, of your own. In addition Git uses a staging area in which you "compose" a commit before you commit it into the repository. This concept is vital to understand and not be confused by the git-way.
Speaking of the git-way... there are graphical tools. I don't use them. The terminal makes me understand git much better and the visualisations are often making me confused.
Here are all the commands I know and use:
- git -? and git [command] -? - shows the help. And it's actually pretty good. git branch -? for example
- git clone [URL] - creates a local copy of a repository that you can work in. Git adds a link back to the repository you cloned as a remote repository called "origin". git clone https://github.com/torvalds/linux.git for example
- git checkout [branch] - branches are lightweight in Git and you find yourself switching between them often. This command does exactly that. If you add a "-b" to the command you create a new branch. This is useful when you start working on a new feature. git checkout -b 'MyNewFeature' for example
- git add [file] and git rm [file] - are commands that add and remove files to the staging area for your commit. With these command you build up your commit into a nice shape before you commit it into the repository. git add --all adds all your changes
- git status - shows how your staging area looks right now. This is run often. Like a tick almost.
- git commit -m '[commit message]' - commits the changes in your staging area into your repository. Commit often. Very often. git commit -m 'GetPersonFromDatabase test written'
- git push [remote] [branch] - this command pushes the committed changes in your branch to the remote. For example git push origin MyNewFeature pushes the changes committed into the MyNewFeature branch to the origin repository.
- git merge [branch] [branch] - merges the changes in one branch into the other branch. git merge master MyNewFeature merges the changes of MyNewFeature into master
The only thing I often need to look up is when you start locally and then want to push it to a remote, like GitHub. Often I create an empty repository at GitHub (great wizard to do that at GitHub) and then git clone that URL. But when I haven't... I'm at a loss. So for me only; this is a workflow for to start locally and then push to GitHub (or another remote).
First start as normal locally:
- git init - creates local git repository.
- do some initial work, like setting up the folder structure and the package.json
- git add --all - adds all the file to the staging area
- git commit -m 'Initial commit' - commits the change set to git.
- Create repository at GitHub
- Get the url to the repository, for example https://github.com/marcusoftnet/ TheNewProject.git
- git remote add origin https://github.com/marcusoftnet/ TheNewProject.git - to add a remote repository called origin to your local repository. When you first create it locally it doesn't have any remotes. Of course.
- git push origin master - to push your current master branch to the origin remote (aka GitHub).
I hope you found this useful. I know that I will. This kind of knowledge is what's fall out of my head quickly if I don't use it.
No comments:
Post a Comment