git push origin master Git and Github - must know commands to make your first commit

#github #git #gitnewbie #tips

You want to learn github and how to contribute to the open source? You don't know how to use github with all its powers?

The Git environment is a vast and sometimes gets very complicated when you have to work on bigger projects. These days almost every software company use github as their first version controlling system.

By understanding these must know commands you will become an even better web developer.

I assume that you have already cloned your repository and are ready to just make your changes and push. So let's get started.

[git status]

Check if there are already some changes tracked in the repository by git? git status will list any files that are changed.

[git add .]

This is the first command that you'll run after making some changes to the project files.

The command analyzes all the repository files and adds all modified and new (untracked) files in the current directory and all subdirectories to the staging area (a.k.a. the index), thus preparing them to be included in the next git commit which I'll explain in the next lines. Any files matching the patterns in the .gitignore file will be ignored by git add .

[git commit -am "your commit message"]

git commit -am adds the changed files into a commit with a commit message as stated inside the inverted commas(in the hading). Using the option -am allows you to add and create a message for the commit in one command.

The -a flag is used in git to add all the files to your commit and then you'll have to run another command where you write your commit message.

The m flag is used for connecting a commit message to your commit for example `git commit -m "your message".

Be very careful when using this command because it will add all the changed files to your commit which you may not want in many cases. You can add individual files to the stging area by using git add. For example git add file1.js image.png index.php to add only "file1.js", "image.png" and "index.php" to the staging area and then you can create a commit with git commit -m "your commit message".

Hence git commit -am "your commit message" is the second command that you must know.

[git push origin master]

You are ready to push your first commit to the remote repository. The push here is for pushing your changes which requires a branch to push to call it origin and then specify the branch name master (the default branch that always exists on any repository.

So git push origin master will take the local commit that you made in the above sections and upload it to the remote server on github for other people to collaborate.

What's next?
Now that you know how to make your first commit and push it to the remote repository here are some other commands that you should know to start working on a team project.

[git pull]

Suppose you are now another dev working on the same repository so you'll have to use this command to pull in the changes that you just pushed to the repository before making any commits. If you don't pull then GitHub will yell at you that you need to pull first.

[git checkout -b "new-branch"]

You'll need this command too often while collaborating on a project that has more than one devs working on it. It creates a new branch for you with the name of the branch stated in the inverted commas (another gotcha here is the hyphen separated name for the branch which is necessary).

You can see in gifs above that there is (master) written after the name of the folder where you are running the command. That (master) is the default branch that gets created in every repository. If you see (master) in your command line then the `git checkout -b "new-branch" will create a new branch based from the master branch. In other words, the branch you check out to will be based on the branch name you see in the command line so be careful about that.

Once you have checked out to a branch you'll be able to work in a detached environment having all the files from master. This way if you mess something you just go back to master branch and you'll have the initial files back. Many professional devs like to work like that.

Final notes

Here is a gist of what we have learnt so far:

Git task	Notes	Git commands
Status	List the files you've changed and those you still need to add or commit:	`git status`
Add files	Add one or more files to staging (index):	`git add <filename>` `git add .`
Commit	Commit changes to head (but not yet to the remote repository):	`git commit -m "Commit message"`
	Commit any files you've added with `git add`, and also commit any files you've changed since then:	`git commit -a`
Push	Send changes to the master branch of your remote repository:	`git push origin master`
Update from the remote repository	Fetch and merge changes on the remote server to your working directory:	`git pull`
Branches	Create a new branch and switch to it:	`git checkout -b <branchname>`

To become a better software developer you need to learn these workflows because they not only boost your productivity but also adds confidence to your way of working that if you break something it can be reverted.

And finally some tips

Don’t EVER commit private keys / api keys/certificates.
Integrate linters and code checkers and beautifiers such as jsPrettier (but first ask your team first if they use any)
Use descriptive commit messages and branch names.
Create a branch for every new feature, and delete the branch once the feature is merged into main.
Tag your commit messages with the ticket number it corresponds with (if you are working in an agile environment)

Top comments (6)

Károly Balogh • Jul 16 '18 • Edited

Helpful article for beginners, but. And it is a big but:

Anyone who uses -am to commit all the things is, of course, in a state of sin.

No, seriously. There is no amount of "I am in a hurry" or "lets take shortcuts" or "I know what I'm doing" justifies omitting the review your changes and adding them one by one instead if necessary. The amount of bugs I catch in the work of otherwise talented young engineers just because they used -am as a "fire and forget" method to commit things is staggering. And it just leads to bad practices in general.

Honestly, I wish more people would use git add --patch instead, and split up their commits to smaller ones, instead of just listing all the changes in a three line commit message, and forgetting half of it (because they won't notice what -am just did for them).