I’ve been using Github for two years, but only had a rudimentary idea about the whole thing.
The tutorials were too long and the names too confusing for me to put in the effort to really learn Git.
This is an attempt to write the guide I wished I’ve found 1½ year ago. And (maybe mostly) to remind myself what to do when I forget :-P
For installation and motivation, look somewhere else.
The command line is all you need – and it is less confusing for beginners in my opinion.
On Windows you can use the native command line, but with the Git installation comes a Linux-like command line called Git Bash. I prefer the power of Linux, but it’s a matter of taste.
A simple thing like being able to clear the window by typing clear is nice though, and Windows lacks the powerful tool grep that can search for anything and take regex-expressions.
Once you are in your new project folder (mkdir proj, cd proj) you can ask Git to track your work by typing git init. This will make a .git folder you don’t need to interact with.
Your local repository lives in the .git folder and contains a copy of the entire project throughout it’s history. Often it is a good idea with a .gitignore file to tell Git which files not to track.
If you set up a virtual environment it will often have a relevant .gitignore file.
There are lot of resources on the web that can help build a .gitignore or teach you about syntax if you want to exclude stuff manually.
Note: You’ll need to ask the file explorer to Show All Files to see files preceded by a dot like .git, or use the command ls -a in Git Bash.
Now you make changes in your project and want Git to save a snapshot.
The command git status will show you if there are changes or not. If there are, add the files worthy of being tracked by typing git add <filename> or - as everything most likely should be tracked - add all by typing git add . (The period tells Git to include all changed files).
To actual start tracking the files, type git commit -m “Some description of the changes”.
Omit the -m flag if your commit message needs to be more than a sentence. You will then be taken to an editor to compose the message.
Typically you will want to push your work to Github or another remote repository by git push after a commit.
You can see your previous commits by typing git log (press q to exit), though you often will want to format the output by using one or more of these flags --oneline --graph --7.
git reflog gives similar information, but with information about head status and commit/merge actions rather than commit messages.
In Git Bash you can nickname the combination you like the most by making an alias: alias graph=”git log --oneline --graph -7”. This will let graph have the same effect as typing git log --oneline --graph --7. To make aliases permanent you’ll have to write them to the file C:\Program Files\Git\etc\profile.d\aliases (for Windows 10). You may have to change permissions for the file and delete the file .bashrc in your home directory (~/.bashrc).
Another good alias is alias la=’ls -a’,
After having committed a few changes you can return to your earlier work by typing git checkout 26a47c1 where the number is the first 7 digits in the long number denoting each commit.
If you are using the --oneline flag only 7 digits will be displayed.
To get back to the most recent work type git checkout master. Try jumping back and forth while having you work open in an adjacent window.
To drop work on one machine before pulling newer work from another machine stash your work (save your work like putting it on a shelve for a later that never comes) by git stash and then type git checkout master to go back to the version right after the last local commit.
The stash can be removed by git stash pop, but will not be recoverable. Lookup git stash on the internet for safer ways to deal with stashes like git stash apply.
The commands git reset and git revert gives yet more flexibility to clean up if you mess up.
If you change something in your old work you will not be able to commit or save, because this would conflict with
later work or rewrite history. In the graph you will note that the label HEAD shows where you are. Jumping
back will leave you with “a detached head”.
To be able to work on your old work you’ll need to make a branch: git branch <newbranchname>.
This will photocopy all your old work to another branch where you can work as normal.
You can jump between branches with checkout: git checkout master and git checkout <newbranchname>.
Normally branches is made to try something out without ruining master.
You can do this yourself or someone you collaborate with can branch out. Brances that work out is then merged back into master.
When you are satisfied with the branch you merge it back into master by checking out master and type git merge <branchname>. Basically the changes in the document(s) in the branch is inserted in the relevant documents at master, even if there has been work done on master.
If the same lines has been tampered with in both documents, there will be a merge conflict that you will need to resolve manually.
There is a lot of tools to compare the text and choose what to keep, but it is possible to edit the documents in a simple editor and just remove the unwanted text and the <<, == and >> by hand.
After a merge conflict is resolved (or dropped by git merge --abort) the relevant file will have to be added and committed as usual.
Along the way the command git status can be helpful (or confusing…). Git status always tells you what have been changed and what needs to be done.
If you don’t want the branch in your working tree you can delete it with git branch -d <branchname>, but normally this is only done with small, short lived local branches.
Note: As branches are cheap to make and delete the small, short lived branches absolutely has a use for trying out new stuff without risking wrecking the master branch.
Instead of merge that leaves branches, it is possible to rewind time to where the branch started and then commit to the master branch as if the branch was never created.
This is done with the command rebase and it leaves the commit tree a little cleaner.
To rebase a branch back into master go to the branch with
git branch <branchname>
and then write
git rebase master.
As the branch typically will be a commit or two ahead of master you now go back to master
git checkout master
and do a fast-forward merge to get master up to speed
git merge <branchname>
To delete a branch simply type
git branch -d <branchname>
Git is meant to preserve your work and make going back to earlier versions easy, but also to facilitate working together with others.
Therefore it is easy to share a common repository in the cloud. Here I will use Github as an example.
If you don’t have a Github account start by getting one.
If you have a local repository on your computer you want to share or backup in the cloud, you start with making a new repository at Github with the name of your project – but do not add a Read.me or license.
Once the Github repository is up click the green Clone or download-button and copy the url.
In your terminal you can bind your local repository to the one on Github by typing
git remote add origin https://github.com/someuser/hello_world.git
and then push your work to Github by issuing the command
git push origin master
To get updates from Github use git fetch, git merge
Or better: set the local master to follow the master on Github by writing
git branch --set-upstream-to=origin/master master
After that you can get updates by simply write git pull
This will also make git push the equivalent of git push origin master if things are set up correctly.
Search the net for what to do it if git push and git pull does not work.
If you want to clone an existing Github repository onto your computer use the green Clone or download- button on the Github page to copy the url and go to the folder where you intend the project to live and type
git clone https://github.com/someuser/hello_world.git
Then go to the project folder with cd hello_world and start programming.
Make a dummy project to experiment on and revisit your skills regularly.
ToDo: make a github project with branches to clone and experiment on.
Show branches on remote: git remote show origin
Delete branch on remote (Careful!): git push --delete origin <Filename>