DEV Community

Cover image for Git & GitHub made simple - Two workflows to project setup
Francesco Di Donato
Francesco Di Donato

Posted on

Git & GitHub made simple - Two workflows to project setup

You probably already use Git and GitHub, but just like me until recently you limit yourself to push changes to your code and nothing more. What if I told you that this version control system can offer you much more?

In this post:
  1. Two different approaches to project setup
    • GitHub Workflow
    • Git Local Workflow
  2. Workflow common commands

1. Project Setup 🧰

There are two cases: either you already have a project or you don't have one. Let's start with the latter.

1.A GitHub Workflow 💻

Log into GitHub and create a new repository. Now, at the top of the screen click on creating a new file button.
Creating a new file

Typically a project presents a, so let's proceed to its creation.

However, keep in mind that everything below is applicable to any type of file. creation

Below the GitHub GUI allows you to associate a short and a longer description to the addition you are about to make. For this time leave it as it is, the placeholder will be used. Then click on the green Commit new File button and you will be sent back to the repository.

You created a repository and put something in it. Good. Now you probably want to be able to work on it locally, using your favorite IDE.
At the top right hand, open the Code drop-down menu and choose SSH from the options. Copy the pointer.

Open your favorite IDE and create/browse (into) a directory. To clone the repository locally, open the terminal and enter the command:
git clone[your_username]/[repo_name].git

In my case is something like this:

Run the command and the repository will be cloned 🐑. You now own locally what until recently was only in the remote repository.

This procedure, in addition to cloning the contents of the repository, also created the hidden .git folder. If not, you wouldn't be able to check which branch you are currently on.

Before proceeding with the git workflow, let's take a quick look at the alternative: what to do when you already have a project locally and want to link it to a GitHub repository?

1.B Git Local Workflow ⌨

Create a folder (outside the previous one). We stay on the train of simplicity, so create a Open the terminal (make sure you are in this new folder - navigate with cd .. to go up and cd [folder_name] to enter) and type the command git init. This basically creates the .git folder.

However, before you can upload this project to GitHub you need a remote repository able to host it. On GitHub follow the procedure seen above and create the repository. However, this time do not click on creating a new file since you are going to do something different.
Go back into the terminal and type the command git status.

Git, compared to alternative VCS, uses the concept of staging step 👻: the snapshot that is pushed is not taken from the project itself, but from a transient copy that you create with the command git add [name_of_the_file]. In this case git add To see the change use git status again.

Great, now you need to commit this stage with git commit -m "[Short_meaningful_description]" where `-m" stands for message.

each commit is associated with a unique id. This will come in handy later.

Before you can push you need to link this project to add a reference to the remote GitHub repository. In the terminal digit:
git remote add origin[your_userame]/[repo_name].git

You can find your related SSH pointer on GitHub, in the newly created repository, above.

Once the command is sent, check the outcome with git remote -v and you will see:

Finally, you can push the project - you have to specify where to put it, then on the origin of the master: git push origin master.

You probably don't want to specify the push destination every time you push. If so, use git push -u origin master, where -u stands for --set-upstream. In the future, git push will suffice.

Once the command is run, refresh the repository on GitHub and please 🤩.

2. Workflow common commands

Let's say you make changes to the file.
As you can see, the letter M appeared next to the modified file (in the folder structure). Of course it stands for Modified.
Now create a new file, maybe an .HTML.
This time you find a U. That means Untracked - not yet present in the staging step. Add it with git add index.HTML and check the outcome with git status.

Note: you can to the stage any changes made since the last commit with git add . where the . stands for the whole folder. Alternatively, you can order to add all files with a certain extension (git add *.HTML).

Once the file is added, the letter U is replaced by A. That's right, it's Added.

You happy with the changes, it's time to save the checkpoint with a nice commit. However, this time you want to add a more exhaustive description about the changes and the reasons behind them.
Just digit git commit with no -m "[message]". The console magically becomes an editor and you can write something like that:
When done, hit esc and then type :wq, finally press Enter. You have returned to the normal console - most people run away from the editor, why on earth?

Now push it with git push and that's it.

In case the long description isn't that long, you can use git commit -m "[short]" -m "[long]".

Recap 🥴

So far you have seen two different ways of adding files to the repository.

In the GitHub workflow you added code via the GitHub GUI: you have bypassed the stage of git adding files, as GitHub does it for you. All you had to do was commit. You didn't have to remotely push anything as you were already in remote. Next, you cloned the repository locally obtaining also an already linked .git folder.

Otherwise, in the local Git workflow you have created a project locally. You initialized the .git folder with the git init command. You linked it to the repository on GitHub with git remote add origin [pointer].
Then you have added the new and modified files. Satisfied with the state of the stage you have committed and pushed the changes to the repository.

If you're interested in digging 🕳 deeper, and you are, embark on branching & PR, thus fixing merge conflicts and why not, forking [VERY_VERY_SOON].

🐤 twitter:

Top comments (0)