If you’re a seasoned developer, git is not part of your everyday routine, and if you’re anything like me, you probably don’t even want to do anything without it.
However, quite a few times I’ve dealt with people that never used, and needed a quick introduction to this beautiful and most of the times trouble free version control software.
Set up a repo
Get started by creating a new repository, you can do that in many ways, but two of my personal favorites are through the following Git Service Providers:
Get the repo
You need to clone the repo, so it will download all source files to your local machine.
You can clone using SSH if you import your keys to your git service, so simply via https, which will require your username and password, which is the simplest set up, and therefore I’m covering it here, just do:
git clone [replace with the repo address]
Make some changes
Now that you have the code, make some changes and run the following command from the root directory where your git repo was cloned into:
You should see something like this:
wagner-mac:app wagnersilva$ git status
On branch master
Your branch is up-to-date with ‘origin/master’.
Changes not staged for commit:
(use “git add <file>…” to update what will be committed)
(use “git checkout — <file>…” to discard changes in working directory)
no changes added to commit (use “git add” and/or “git commit -a”)
Now you just have to send your changes to the server, so your colleagues can see what you do. Run the following commands:
git commit -a
The above command will mark everything as ready to go on the remote server. It will also ask you what you did. So you should give it a brief yet meaningful description.
The first line will be the title, such as: Fixed broken contact form
Normally you will only send one line, but if you want to be good, you may also want to give it a line break and some more info, such as:
The form was broken due to some crappy changes made earlier, which I’ve now fixed.
Share your changes with the team
Now that you made your changes, you need to need to share it with your team, but in git, you first need to make sure no one has sent something in first, so you avoid a possible error such as:
Failed to push some refs to
<repo>. To prevent you from losing history, non-fast-forward updates were rejected. Merge remote changes before pushing again.
So before anything you run the command:
This command, update your local copy with anything the rest of the team may have changed.
Then you just need to run
And everything will get sent to the server.
Well, most of the times yes. But as with everything in life things are not that straightforward, but I believe the commands above, will be enough for you to get started, do some work, and when you encounter problems, the basics have already been covered.
Have fun, and keep on pushing!