Version control software (VCS) Tools
Git and Mercurial (Hg) are the actual tools. They are both Distributed Version control systems, which means that developers can work on the same project independently of other team members on their own local branches.
WHO CREATED GIT?
He is responsible for the linux kernel.
Linux kernel is used by Linux Os (Ubuntu/MacOs), Android.
Github is not the same as git. Github is a website/platform while git is a tool.
Choosing the right source control platform for your team is one of the most important decisions you’re going to make. There’s a good chance that you’ll choose Git for the version control software (VCS) itself, but the platform where the code lives is equally important. Many times, it comes down to Bitbucket vs GitHub or Gitlab.
GitHub vs Bitbucket: The Basics
Github and Bitbucket are just hosting platforms. You can use them for your Git projects or Mercurial projects (and may be even for SVN projects).
If you boil it down to the most basic and fundamental difference between GitHub and Bitbucket, it is this:
GitHub is focused around public code, and Bitbucket is for private.
Basically, GitHub(public) has a huge open-source community, and Bitbucket tends to have mostly enterprise and business users.That’s not to say that you can’t have a private repository on GitHub (you can). Or that you can’t post your code public-ally on Bitbucket (again, you can). However, the majority of the users aren’t doing so. Plus, the defaults are set that way, too: public and private repositories respectively.
Outside of that difference, the two platforms function very similarly. You can create and manage repositories through the website or command line, log in with two-factor authentication (2FA), invite collaborators, open issues and discussions, create/merge pull requests, and generally handle all the fundamental things you would need to from the website. They’re super similar that way.
Bitbucket is an Atlassian product (the makers of Trello and other apps), you have a slick and clean interface from the moment you log in. You see immediately that they’re focused on professional teams as an all-in-one solution for software development. Let’s see how.
GitHub, obviously, is a hub for git version control.
BitBucket, on the other hand, supports more than just git. You can also track your repositories in Mercurial, another popular version control management system. It does not support SVN, another major system, but at least with Bitbucket, you have a choice.
GitHub vs Bitbucket: The Winner?
In the end, you’re not going to go wrong with your choice. If you’re a small dev team, either will work almost exactly the same for you. But, if you’re new to git, Bitbucket is a little more forgiving and easy to use as you learn the workflow. If you are interested in open-source development at all, GitHub is the main hub for that.
In terms of business solutions…it’s a toss-up. The paid plans are pretty similar. It’s hard to make any kind of recommendation on that. Bitbucket kind of specializes in business clients, offering an all-in-one solution through Atlassian’s overall suite, but GitHub being the major platform in open-source and public code, if your company is involved in that, they may be the way to go.
In reality, neither is a bad choice to serve you and your source control needs. You can’t go wrong with either, honestly.
React Application Deployment and Hosting Solutions
1. Firebase Hosting
2. Github Pages
You can use GitHub Pages to host a website about yourself, your organization, or your project directly from a GitHub repository.
You can host your site on GitHub’s
github.io domain or your own custom domain.
how to deploy a production React app to Heroku @
7. AWS S3
Jenkins is an open source automation tool written in Java with plugins built for Continuous Integration purpose. Jenkins is used to build and test your software projects continuously making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build.
GitHub vs Bitbucket: Which is Right for Your Development Team?
Choosing the right source control platform for your team is one of the most important decisions you're going to make…
Continuous Integration and deployment (CI/CD Pipeline) with Jenkins and Node.js
Most of the time testing and deployment steps do not change frequently and in order to keep the developer focus on writing code, we do the automation of testing and deployment.
This automation is called “continuous integration and deployment” OR CI/CD Pipeline.
In this tutorial, we will learn how to set up continuous integration and deployment (CI/CD) infrastructure for the Node.js project.
I am going to use Jenkins as the automation tool and Github as source code management system.
Jenkins is free for use but we require public server in order to integrate the Github repository.
Here is the complete flow of the system.
- You made some changes in your project.
- You push those changes in Github on master or any branch.
- Github will notify Jenkins about the new push. ( We will configure it )
- Jenkins will then run the commands you ask it to run.
Those commands will contain the following.
- Test script.
- Deployment script.
Deployment script will be added to Project only and Jenkins will use that to communicate to Server and perform the push.
Basically, what you do manually such as running test command, login to Server, performing Git pull and then restarting build server, we will do all of them automatically by writing the script.
Let’s get down to work
git clone https://github.com/<username>/repo-name.git
git clone https://github.com/codeforgeek/demoapp
Let’s create a simple Express project to deliver the “Hello World” message. Switch to the clone folder and run npm init -y command to generate the package.JSON file.
“test”: “echo “Error: no test specified” && exit 1"
Install express using the following command.
npm i — save express
Ok, so we have our app running with the test. Let’s push it to Github.
First add all files.
git add .
Add new commit.
git commit -m “first push”
Where to deploy your React app and your APIs
You have a React frontend app (created with for example create-react-app), and one backend API app. Both running successfully on localhost.
Now, where do you deploy them so they are accessible on the internet?
Your frontend app is only pure HTML/JS/CSS. All you need is some static file hosting. Two solid options:
Which one should you pick? It depends based on the requirements of your app.
Amazon S3 promises a 99.999999% uptime which is pretty impressive. It is a distributed storage with at least 3 geographically separated locations. This is a robust and reliable platform to run your React app on.
It is not free. But the good thing is you only pay for what you use.
Perfect for: Your or your client’s production application.
Use Github pages if you just want something up and running quickly. If you are already using Github, then you don’t even have to create a new account. And with create-react-app, the deployment is super simple and well documented.
Also, Github pages is free!
Perfect for: Portfolio site, personal web page, a quick demo, etc.
Hosting a backend app is a bit more work than hosting static files. There are modern cloud providers that have automated a lot to make it much simpler than it was before. These are two solid options:
Both these cloud providers support many different programming languages including Node. And they both provide autoscaling meaning your app will be able to handle a lot of users accessing your site simultaneously.
You don’t need to think about installing/configuring an OS or reverse proxy. It just works out of the box. Also, deploying is automated and works with a simple command from your terminal.
You pay only for what you use. That means it’s pretty cheap to throw up a server just to test something out.
If you don’t like the idea that everything “just works” like with Elastic Beanstalk and Heroku, then there is an option for you.
You can buy a VPS (Virtual Private Server) such as DigitalOcean. Then you get access to your own machine that you have full control over. It requires more knowledge about sysadmin and devops, but at the same time, it gives you more control. I would not recommend using a VPS unless you have some very good reason for it because of the added work of configuring/installing it.