Git - Tumblr Posts
bad git tip #1
Ever feel like you want to try out a new git trick, but you're afraid it might cause some problems or break your repo somehow? Wouldn't it be great if you could track the history of your git state and revert if something went wrong?
Well, now you can, with a little trick I call git-git!
Just go into a directory with a git repository, cd into the .git folder, and run git init. Then, cd back out, and create a post-commit hook in the toplevel repository that creates a commit in git-git repository every time you commit in the toplevel repository! Now your git history is being track by git, and you have all the powerful tools that git gives you at your disposal. Never worry about doing fucked up shit in git again!
it's an alias
i forget the command, but essentially, it echos "all gud" if you are in sync with remote, and "not gud" if you aren't.
Does anybody know anything about this "git gud" command? People keep telling me to use it, but I can't get it to work.
[me talking to git like a midwife]
you're doing great! now push! PUSH! that's it, you're almost there! don't stop, I can see the HEAD! that's it, you did it!!
8 commits, 12 changes. a healthy baby branch! it's a miracle to witness every time
I love going viral on tumblr.com. It’s like if you stood in a field and said some of the stupidest shit a human being is capable of and then like fifty thousand crows attacked you
Going to make a "Getting started with GIT" Post
(This is my getting the "why are you making that post" out of the way, so that the posts with the actual information does not get polluted by it. And also polling people on what they find confusing about GIT so I can target that a bit better) So I re-blogged a post with a really nice GIT diagram, showing what commands sends what where. And I noticed 3 things in the replies and reblog. 1: A lot of people seem to be intimidated by the perceived complexity of GIT. That is fair. But I promise, while HOW it works is complicated, using it is not. 2: Many have it on a TODO list for after they learn to code. Which is... backwards. It would be like waiting with learning how to use a keyboard until after you have become a good writer. Trust me, learning GIT as one of the first things will make it EASIER to learn to code. 3: Several people suggested that GIT is overcomplicated. That is... simply not true. It is one of the old school pieces of software (Meaning it does 1 thing, is open-source, free and is impossible to monetize). It does something very very complicated in the simplest way possible. I think people simply do not understand how complicated the problem GIT solves is. I am not saying "People are dumb" (I think... anyone thinking that is fundamentally missing something in how the world works.), I am saying "People seem to be either misinformed or not informed". And that I can help with!
I WILL make a "Getting started with GIT" Post, but if people want an easy explanation for something more, then I will also make posts for those later... Or maybe they fit in as part of a getting started post. We shall see
A beginners guide to GIT: Part 1 - What is GIT? Why should I care?
Table of content: Part 1: What is GIT? Why should I care?
Part 2: Definitions of terms and concepts
Part 3: How to learn GIT after (or instead of ) this guide.
Part 4: How to use GIT as 1 person
Part 5: How to use GIT as a group.
GIT is a program used via a shell that allows you to save your text based work.
… no really, that is it. That is what “source control” basically means. Nothing mysterious, nothing complex. It saves. But it saves in a way that gives you extra features! So you can also:
Go back and forth between any time you saved in seconds (So the saves are more like saves in a video game, than saving a file)
Have GIT tell you what changes happened between 2 saves so you can find bugs
Have GIT find which commit last touched a function or file so you can find out when bugs got created Sexy right?
Furthermore, GIT allows many people to each work on the same project at the same time. Even the same files and the same code. There are other fringe ways to use GIT, but most use one of 2 ways: 1: Local repository. Basically, a local save, used just by you. Easy peasy. 2: Remote repository. The project has a central save file on a remote server. Everyone wanting to work on the project copies this, and starts working on their different parts. When someone has a chunk of work done, they update the central save file with their work. When you do this, GIT makes sure that the different changes do not interfere with each-other. And if they DO interfere, GIT makes it as simple as possible to merge the 2 changes together.
And it does it while using less than a dozen kilobytes of space. Even for huge projects.
Here is the second best thing. GIT scales perfectly from a single person project to gigantic projects with thousands of developers. You can use GIT , and only GIT , and no matter how your project grows, GIT will still be a good fit for you.
And the best thing? The complexity of using GIT, scales with the complexity of the development environment. For a single person, it is super simple, and completely pain free For small teams, it needs a small amount of work and agreements For large multilayer development teams, it needs somewhat rigid standards for doing things and several people dedicated to making it run smoothly.
This is why the “Use GIT” advice is so universal. Because no matter what you are doing, if it is text, then GIT is THE source control tool to use. When your code is breaking at 2am and you have lost track of what you changed when and where, GIT will save you! Many newbies (me included) who did not use GIT, have had to scrap entire projects because they simply could not un-break them again.
A beginners guide to GIT: Part 2 - Concepts and terms
Table of content: Part 1: What is GIT? Why should I care?
Part 2: Definitions of terms and concepts
Part 3: How to learn GIT after (or instead of ) this guide.
Part 4: How to use GIT as 1 person
Part 5: How to use GIT as a group.
Now, a few (I PROMISE only a few!) concepts that are needed for being able to talk and read about GIT.
Just to be difficult, several of these have multiple names (Plø!)
GIT refers to its commands as "porcelain" commands (user friendly and clean) and "plumbing" commands (Not so user friendly, dirty). Yes. We are starting out with references to toilets :p
The workspace/working tree is all the files and folders you would have if you did not use GIT. It is folders, codefiles, headers, and build system files. All the good stuff we want to work on.
A repository is technically the hidden folder called “.git”. It is all the files GIT uses to keep track of your files and their history, and which enables you to do all the git things to the files in the working tree. You do NOT have to interact with these directly. Just know they are here ( Sometimes people refer to the working tree AND the repository together as “The repository”. Because we work hard on making life harder and more confusing than it needs to be)
The index/cache/staging area is a single, large, binary file in the .git. folder. It keeps track of the differences between last time you saved, and how the working tree is now. Every change, every new file, every file deleted.
Commit. To differentiate what GIT does from how you normally save files, we use the term “commit”. But it is just a save. Different commits are different saves. Easy peasy. Every commit, except the very first one is based on the commit before it. That is called the commits base.(This is the base that REBASE refers to).
The structure of GIT is actually very simple. It is a whole bunch of commits, and each commit knows the commit it came from (IE all commits except the first have a base). This makes a long chain. That's it. That is the entire idea
Staged files
So you now know that we can commit(save) and we have files that we change, but have not been committed. We need a name for files between those two. Files that we are getting ready to commit. All files that will be committed if you commit RIGHT NOW, are “staged for commit”.
HEAD. Because you can switch between different commits easily, we need a way to say “what commit are we looking at right now?”. That is HEAD.
HEAD can be “detached”. This basically means that the commit HEAD is pointing at, is NOT the latest commit. And while you CAN do work on a detached head, it gets messy and is not the smartest way to do it, so “detached head” also works as a bit of a warning.
(If you have ever worked with pointers, HEAD is simply a pointer to a commit)
If we make 3 commits, one after the other (which means HEAD is pointing at the last commit), then your commits could be represented like this:
Branches. These are commits that are done one after the other. You always have at least your starting branch (Usually named master or main). If you create new branches, then they start from a specific commit and can be merged into the original branch whenever you are done.
If we expand the previous example, make a branch from the first commit, and then merge it before the third commit and delete the branch, it could look something like this:
Make the branch and add to it:
Then merge it into the main branch and delete the new feature branch:
origin/upstream. This refers to what commit and branch a branch came from. In our example, the "New feature branch" would have the upstream/origin "Main branch" , "Initial commit".
A beginners guide to GIT: Part 3 - How to learn GIT after (or instead of ) this guide
Table of content: Part 1: What is GIT? Why should I care?
Part 2: Definitions of terms and concepts
Part 3: How to learn GIT after (or instead of ) this guide.
Part 4: How to use GIT as 1 person
Part 5: How to use GIT as a group.
First of all, GIT have a website:
And besides downloading GIT if you do not already have it, it has THE GIT book. It is honestly very good and contains quite a few translations
Second, GIT is one of the old pieces of tech. This means that it is open source, free, and that it contains its own documentation and guides.
If you are ever stuck, or confused about something in GIT, you can use the help command.
Simply writing
git help
Shows you the porcelain commands, and tells you that adding the option -a like so:
git help -a
gives you ALL commands
and the option -g gives you all the guides the manual have, like so
git help -g
If you give help another command,, it will bring you to the manual page for that command
for example, someone on the internet told you to write
git help reset --hard
and you want to know what that means before running it? Write
git help reset
And you will be shown the manual page for “reset”. Including what --hard does. (To understand the manual, you need to understand the concepts and terms from part 2.)
If you want more visual explanations, Atlassian's guides are public and also quite good (But , remember. Atlassian uses Bitbucket. Bitbucket is 99% GIT, but can still have tiny differences)
A beginners guide to GIT: Part 4 - How to use GIT as 1 person
Table of content: Part 1: What is GIT? Why should I care?
Part 2: Definitions of terms and concepts
Part 3: How to learn GIT after (or instead of ) this guide.
Part 4: How to use GIT as 1 person
Part 5: How to use GIT as a group.
When it comes to not getting in each other's way, working alone is the simplest (It has a lot of other drawbacks). This is the simplest way to use GIT. You can do it with an external repository as a backup or just locally on your computer. It depends on how important your project is. If your laptop crashes tomorrow, which projects would you have a really hard time losing? Better to have an external backup for that. Github is often used for this (Maybe less now that Github makes machine learning AI’s, and so ARE stealing your code to train their AI on.) but you can also use Bitbucket (Which... may also steal your code...) and there are many many others out there. GIT is often used in certain patterns, called “workflows”. These have you working in more or less rigid ways to make it simple to work together. But since you are working alone, you do not risk others changing your code while you are working, so you can do it the simplest way :D
I will be doing a step by step guide that you can follow along. I will be doing it on a completely empty project and making a tiiiiiny program in C. This is because it is super simple. You do NOT have to know C to follow. You can also follow the steps with your own already existing project.
I PROMISE you, GIT cannot hurt you. Worst case scenario is that you fiddle around and break the repository part. (Meaning the files in the .git folder). But your files will always be safe.
(If you do not have git installed, check out part 3 for that)
First, I make a folder, navigate my shell into it, and call git init:
By the way, you can get used to GIT messages like this that tell you all your options, and explain what GIT has done for you. GIT is very good about giving you as much help and info as possible,
Now I will teach you the most important command in GIT.
It is more important than any other. Ready?
git status
This makes GIT tell you what git thinks is happening right now. What issues there are and what files are tracked, untracked or have been changed. Use this command often, especially while you are new to GIT, run it after every other command. It is how you learn what GIT is doing and thinking :3
Since our repo is empty it tells you what branch you are on (master. The only branch we will need since we are working alone)
and that you have not made any commits.
It also tells you the commands git think you will want to use on files. Since our repository is empty, it tells us to create some files, and then how to add them :3 So let's do that:
I have added my tiny program, as you can see:
Now let us see what GIT thinks we did:
Now, since there have been changes, git shows us them.
Files can be untracked tracked and not changed (In which case, git status does not show them) tracked and changed.
Right now, main.c is untracket. Which basically means GIT have no idea about this file, other than it is in the folder.
Ok, let us commit(save) the file. GIT tells us this is done with git add <File> . So we will write git add main.c
Then we use git status again to see what happened git status
And yeah, our file is now ready to be committed. So lets do it! git commit -m “My first commit!”
The “-m” option is to write the git update explanation directly in the console instead of using an external program to do it. Done You have now committed your code! It is now saved!
git status shows that everything in the working tree is as it was last time we committed (Duh. We JUST committed)
I will now make some changes to the main file:
Git status shows us main.c was changed...but what if we wanted to know what was changed in more detail? How will we get status to do that for us? Let us find out! git help status
git then shows the help page for status And there we can see this part:
So if we write status with 2 -v arguments, we get all the details. Let us try:
And look! It shows us EXACTLY what lines were changed! I stage the changes and commit:
And you have now learning enough about GIT to use it.. You now have all your work saved, in different commits. If you ever want to know all the commits you have made, write git log:
And if you want to know what a specific commit did, you copy the name of the commit, and write git show:
Now, everytime you want to save your work, you
1: Write/change the files you want
2: Add the files you want as part of this commit
3: make the commit These three steps are your workflow.
If you have a remote repository, then you add them steps
4: push to remote repository
To do this step, you can actually just write
git push
If you have set up a remote repository, then it just works. If you have not, then git will tell you what to do Whichever remote repository you use will tell you if you need to do other steps, like setting up passwords or ssh keys. They will also tell you how to set up the remote repository (That is not a GIT thing, that is a bitbucket or a github thing, so refer to whichever of those sites you want to use) And that is all! Every time you commit, your project is saved (it is smart to commit often, but usually only commit when your project can be compiled.) And whether you use a remote repository or not, you now have a fully valid GIT repository, and all the git tricks can be used on your project!
A beginners guide to GIT: Part 5 - How to use GIT as a group.
Table of content: Part 1: What is GIT? Why should I care?
Part 2: Definitions of terms and concepts
Part 3: How to learn GIT after (or instead of ) this guide.
Part 4: How to use GIT as 1 person
Part 5: How to use GIT as a group.
For this, I will describe a workflow, called “feature branch workflow.” There are others that are simpler, and are sometimes better, but I will describe one that always works, for any amount of people, and most likely is what your future workplace uses.. And yes, it involves branching (which sounds scary, but it is not so bad.)
Why? Well because of 2 goals we have that somewhat clash.
1: To use GIT in a way that is easy on ourselves and will give us all the benefits of GIT. This means committing often. Pretty much every time we have made a change, and we can compile.
2: We want to sync our work with our fellow workers. But this takes effort every time we do it because we might have made changes that clashes with changes someone else have made.
(Notice though that this is not a problem originating in GIT. This is a problem that comes from people working together on the same thing. GIT just makes it easy to spot the problems and describe them in an accurate way.)
We alleviate this by only syncing up when we have made a larger chunk of self contained work. Usually we use the term "feature" for this. And they can be quite small (For example 4 commits, making a "Return to previous page" button ) or large (For example, 38 commits, which also used branches, to implement a GUI on top of the backend code we have made).
It is best to make features as small as you can, so that a feature branch does not end up being an entirely different sister project to the main branch.
The first thing we do is declare the main/master branch holy. Just like any branch, it must always compile, but now we add " May only have fully realized features". It must ALWAYS be ready to be shown to the customer/your boss/your adviser/your teacher.
So when we want to do some work, we coordinate it with our teammates so people are not working on the same thing, and thus wasting their time. ( This can be done with tickets, verbally at meetings, in group chats. Whichever fits your team )
Then we make a branch with its base at the tip of the main/master branch. We then do work, commit and push every commit onto that branch. This has all the benefits we had from working alone. We cannot get merge conflicts, as we are the only one working on this branch.
So let us show how this works! For this example I have set up a remote repository on bitbucket containing only a standard README that I have not written in at all., I then cloned it down in 2 different directories. Each of which I have opened with a console. This is how I will represent multiple people:
So first, we show off one person making a change, and the other getting it. So I add a main.c file in there, add it so it is staged for commit, and then commit it:
And if we write git status, we can see that we are 1 commit ahead of the remote repository:
We then push our commits to the remote repository:
The other user can now use git fetch (Which gets the latest information from the remote repository, but does not change anything):
We then pull the latest update from the remote repository with git pull:
This is the simple way to work. But of course, if we have changed the same file, we will get a merge conflict.
As we talked about, we will minimize those by using branches. So we will say that each of these two people now will work on a different feature. Each of which will be a function that prints something. And each will be in another c file, with a header. We will do this with branching. We want to make a branch, and then switch to it. Switching to branches is called “checkout”. We can do both in one step by checking out a branch that does not exist, with the option -b (You can as always read about checkout, by writing “git help checkout”)
git checkout -b My_Spiffy_Feature
When we then write git status, we can see that we are on the new branch:
I then add the new files. with the new function in, and we want test that they work by calling the function in main:
We then compile our program (which gets default name a.out) and run it:
It works! Great, time to commit. We add the new files, BUT NOT main.c or a.out . They were just for testing, and is otherwise not related to our feature.
And we then push to the remote repository:
As you can see, git complained, because while we have created our branch, we had not really configured it yet (Specifically, we never told git what branch this new branch should originate from from. We just created it out in the void). But GIT TELLS you what to do. So I simply wrote the recommended command, and bam, branch is working as we want it to
I update the new feature file, just so we have more than one commit. I add the changes, commit and push again:
Now that our feature is done, we want to merge the branch into the master branch.
To showcase something, I will first have the other person make a change to main, add, commit and push it:
The first person will now merge their spiffy new feature in. They do that by switching to the master branch with git checkout:
We see that we are behind 1 commit, so we pull.
But horror! Since we have the unstaged changes, we cannot pull, since we changed main.c to tests our new feature, AND the other person have changed main, those two cannot exist at the same time. So what do we do? Well, in this case, we are ok with our tiny test in main.c being lost. So we remove it like so:
Notice how EVERYTHING I did here, was just read what GIT said was the problem, then write git status, and do the actions that GIT tells me I can do, which solves the problem. Ok, now we have the latest update of the master branch. Time to merge our feature in:
This time I did not use the -m feature (Because I forgot) so I just used the external program to write the commit message.
And if we write git log, we can see every single one of the commits. Both in the branch, and in the master:
And if we want to get a bit of a graphical representation of what happened, we can use git log --graph:
Now, this is the simple way to do branching. You actually have full control over how exactly you want to merge your branch in. In this case, the two commits of the branch was added AFTER the commit on master. But we COULD have merged the branch in so that the two commits on the spiffy function was done BEFORE the changes on master. When you are still starting out, do not worry about this. But that is the workflow. You create a branch, you work on your feature in it, where you cannot get in the way of anyone else. When your feature is done, you merge it into the master. This way, the master was always ready to show to your teacher/boss, and did not have half implemented things that you would have to explain should be ignored at any point.
Half of the benefit of the feature branch workflow is that it minimizes the chance for merge conflicts. For them to happen, 1 group would have to go to the master branch and pull. AFTER they pulled, but before they managed to merge their branch in, another group must pull from master, and merged their feature in.
Unlikely.
But let us talk about merge conflicts.
Are those not horrible things that break everything?
No. Merge conflicts simply means GIT could not figure out how to merge something, and so a human will have to do it for it. GIT is nice, and shows you exactly where the problem is, and how to solve it. Let us create a merge conflict. The first person adds in the function that uses their new spiffy feature after the hello world prinf, stages the changes and commits them. But do not yet push
The other person creates 2 more printf statements in main, stages the changes for commit, and commits them:
Now we have 2 commits, that both changes main.c How should these two be merged? Should the spiffy feature be called before or after the newly added prinf lines? GIT cannot know this, and so will tell the humans to do it. And the job falls to whoever wanted to push in a change that creates the merge conflict. In our example, I will have the second person, who added the extra printf lines push first:
And now the first person with their spiffy feature pushes, and:
It fails... But we are fine. Nothing actually happened here. The remote is still fine, and we locally are still fine. But we have to figure out how to fix this. When in doubt, use git fetch to get all the info but change nothing, and then git status:
(By the way, I made an honest mistake here, and did not push the branch changes after I merged. But I am not really in trouble, because GIT saved me! :D) And as we can see, GIT is once again telling us what to do. Great!
And we are now at the place where we need to decide what to do. While you are still new, I recommend the default strategy. So we do as GIT tells us to:
And now, FINALLY, we have our merge error. But notice that we only got it this way, because we asked for it. So… what does that mean? Git status to the rescue once more!
As expected, the problem is in main.c Let us check out what is in that file:
We have our changes first, then a separation, and then the other changes. And fixing it is piss easy. We remove the lines GIT inserted to tell us where the conflict was, and put the code in order. WE decide if the spiffy feature should be put before, after or in the middle of the two printf statements. I decide to put them in the middle like so:
Merging the two versions together, is in of itself, a change to the code. So we will now do what we always do when we have made changes. Add the files that we changed, and make a commit, and then push:
We have now resolved the merge conflict.
Notice how the problems that we ran into were not GIT problems. We ran into issues that ALWAYS come up when multiple people are working on the same project. But GIT made it really clear what the issues were, and forced us to deal with them in a smart way! :D
FINALLY got done with the Beginners guide to GIT
So a long time ago I made a poll to help me make a Begginers guide to GIT because a lot of people seem to have trouble with it. https://www.tumblr.com/moose-mousse/722172571753365504/going-to-make-a-getting-started-with-git-post?source=share
And I know for a fact that my University taught it horribly. (Or rather... did not teach it at all)
I REALLY tried making this guide as short as I possibly could. Explaining only what you need to know, while trying to clarify what most people find confusing. But it still is too long for a single post. So, I have split it into 5. The post each links to each other, so you should be able to go back and forth easily.
This guide is going to be pure GIT done via the command line. 2 reasons for this:
1: GIT GUI’s are really handy, but they abstracts away a lot of the newbie help GIT is trying to give you. Bitbucket, Github, Jira, and other services use GIT but usually add extra bits that are specific to them. So to know how they are different, it is smartest to learn pure GIT first. And since they are 99% GIT, you will be able to use them with no/little trouble.
2: Because I use the command line, it is easy to build your own automation tools. Simply have a program write git commands to the shell and/or read outputs from git commands and use them to visualize whatever you want, however you want. That way you can have whatever shiney graphics your heart can code up. All the tools you can find (Like Github desktop or gitk) are simply doing this. (incidentally, if any of you make a pretty visualization of GIT? Show me! I wanna see a dog themed GIT graph! I wanna see pink log outputs! Make it yours!)
Table of content: Part 1: What is GIT? Why should I care?
Part 2: Definitions of terms and concepts
Part 3: How to learn GIT after (or instead of ) this guide.
Part 4: How to use GIT as 1 person
Part 5: How to use GIT as a group.
I just downloaded a program, as a git repository. It allowed you to have it work in several different ways. Which was achieved by simply using "git checkout" to check out whatever branch you want. I love it. That is so smart!
Honestly... my advice when people ask how to learn git is:
1 Open a console.
2 Write "git"
3 press enter.
Now read and follow instructions.
Git is OLDSCHOOL.
Meaning it is a self documenting program
If you write "git" and follow what it says, it have you creating a dummy repo as the second command it tells you to use in the tutorial.
So "just write git and press enter" gets the same result as your recommendation :3
Honestly... my advice when people ask how to learn git is:
1 Open a console.
2 Write "git"
3 press enter.
Now read and follow instructions.
Git is OLDSCHOOL.
Meaning it is a self documenting program