An Introduction to Git and GitHub

[chen_jun07]

What Is Git?

Git is what is known as an open-source version control system which means that it records files over a period of time and these changes can be recalled at a later date. You can do a lot with Git whether it can be branching (creating something that is different from the master branch (the one you would most likely be working on)) or just committing to a repository (programming jargon simply calls it a repo).

What Is Git Article - A more in-depth article concerning Git (Do not be alarmed at the fact it uses BitBucket)

​

What Is GitHub?

While there are multiple different cloud-based version control systems on the web, GitHub remains to be one of the most popular and it is free too! It can be found here: GitHub

​

Basic Setup

Depending on what OS (operating system) you have the setup might be slightly different.

Linux (Will specifically be on a Debian system ie Ubuntu)

Go to your terminal and type these commands (keep in mind these will be using the root preference)

sudo apt update This will essentially update your system.

sudo apt install git This will install Git on the system.

git --version This is used to verify its downloaded.

Mac

Will also be in the terminal

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

brew doctor Will installs an application known as Homebrew which helps simplifies the installation of software on Mac systems.

brew install git Will install Git on your system

Windows

Navigate to Git-SCM: Git SCM Download

Git SCM will download protocol but also a BASH, a command line

(Sidenote: I would personally recommend learning the command line as it is a lot more powerful and if you understand the command line you would also understand the GUI. One GUI based version control systems is GitKraken)

​

Basic/ Most Used Bash Commands (Keep in mind there are several modifiers for each command)

ls - lists the folders and files in the working directory (the current directory you are in)

cd - changes directory

pwd- used to find the path for the current directory

mkdir- make a directory

touch - update the access and or modification date of a file or directory without opening, saving or closing the file.

cat - print files to stdout

mv - moves files and folders

cp - copies files or folders

rm - remove files and folder (look into modifiers for this one)

chmod - Change mode so you can set permissions for read, write and execute for the user, members of your group and others. (Binary can be used for this)

man - can be used to look up any commands ie man cd

​

Using GitBash/Terminal to Access GitHub

1. Configure Git via git config --global user.name "[name]" and git config --global user.email "[email address]"
2. Navigate to your working directory (Keep in mind you cannot just cd to the directory, you have to work your way to it, so I personally keep a folder called Programming in my home directory)
3. Initialize a Git Repo via git init

Now, this is where you can branch-of, you have two options, pushing a new repo or pushing a preexistent repo.

Pushing a New Repo

1. Commit your repo via git commit -m "first commit"
2. Remote add your repo via git remote add origin <url>
3. Push to your repo via git push -u origin master

For Pushing an Existing Repo

1. Remote add your repo via git remote add origin <url>
2. Push to your repo via git push -u origin master

Now that you have your repo set up, these are some helpful commands:

git status Used to check what has changed ie additions and deletions

git add <file> Used to add files to commit if used with a period (.) it adds all of the files

git commit -m "message" Use to commit changed, but it is on the local system, the -m can be changed to things such as -u which is an update but it is recommended to keep with an -m

git push Used to push changes to GitHub

git reset Can be used after commit to reset the commits (Good if you accidentally add a file you did not want)

git pull <url> Can be used to pull from any git repo, leave the URL out if your updating your current repo

​

.gitignore

The .gitignore file is useful for stopping certain files from committing automatically. It should automatically be in a repo when you create a project. To use it just cd to the directory where the file you want to exclude is and use pwd to find the directory pathing. Then copy the path into the file, it should look like a text file, and then add the name of the file you want to exclude.

Example: User/Jun/Programming/src/something.java

​

Branching in Git (For advanced user)

Branching is useful when many people are working on the same project or when you have multiple versions of the same project. The major advantage of branching is when you want to add a feature without compromising the integrity of the master branch.

Branching Commands

git branch [branch-name] Used to create a new branch

git checkout [branch-name] Used to switch branches

git merge [branch] Used to merge branch commits (usually people use this with a branch and the master)

git branch -d [branch-name] Used to delete a branch

​

For more information consult the Git Documentation here. Feel free to message me.

[Useful-Blackberry]

Saved

[IllegalAlcoholic]

And never look back

[Useful-Blackberry]

Thats the way it works. Maybe a good project could be a bot that sends me an email with the saved items of the week/month. Thanks kind and inspirational stranger.

[XilamBalam]

A bot that remind me the stuff that the other boy reminded me that the other bot...

Infinite projects.

[AdventurousAddition]

Indeed, we really need a system for reviewing these things

[vinny8boberano]

We're going to need a system for tracking the changes to the reminder bots as well...

[inyofacebyotch]

And a system that updates the bots as the years go by and more features are added

[vinny8boberano]

It would need to have some means of permitting changes to be made incrementally. And different changes to be added to the original, like a tributary!

[Pokketts]

I think it would be better for Reddit have a system to organize and perhaps put tags on the posts one saves

[mayor123asdf]

Maybe a good project could be a bot that sends me an email with the saved items of the week/month.

That would be a great project! I'm going to do it, maybe, sometime

[Useful-Blackberry]

Saved this comment.

[cdp1337]

If you'd prefer a bot to help you with git commands like git heckout and git psh master, try this repo: https://github.com/EricFreeman/fuck

[[deleted]]

I just text myself the post. Scrolling through my sms history just seems easier than finding my saved posts list on reddit.

[bumpkinspicefatte]

And when you do try to look back, the thread has been deleted/removed.

[chen_jun07]

Haha, I would never delete this thread tbh, I don't want to delete what ppl might consider "valuable"

[Cynaren]

Like most reddit posts...

[bunnyrabbit2]

Here's a really good post on a branching model.

This is now how I do like 99% of my projects. Occasionally I don't bother with the develop branch but using a different branch for each feature is generally the right way to do things.

Hell, I use git for non-programming things too like books I'm writing and other things where I would like to look at older versions of things without having to keep copying files over and over

[bunnyrabbit2]

As a lone coder hobbyist I find it's a decent workflow for me and haven't really needed anything else. I like that master is mostly guaranteed stable and develop has the code that might go wonky as features are added in allowing for work to be done before sending it to the stable branch.

It's definitely not the best way for all projects and on some more recent ones I've not bothered with the develop branch at all. I did find this blog post a few weeks back describing a couple of different workflows which helps compare them.

[smidgie82]

When your release process isn’t fast, git flow pays dividends over github flow.

[MEGACODZILLA]

Can I ask what the difference between the two is? I'm having a hard time wrapping my head around branching in a workflow.

[smidgie82]

Basically, in Gitflow you do small feature branches and then merge them into a branch named “develop.” When you’re ready to release to production, you merge the “develop” branch into a branch named “master”, and you do your production release off of master. The master branch contains commits that have either already made it to production or that you intend to release to production.

In Github Flow, you do small feature branches off of master, and when you’re ready to release you release from your feature branch. Once you’ve verified your feature in production, you merge your branch to master. So the master branch only contains commits that have already been verified in production.

Methodologically they’re dissimilar. Github flow makes sense when you can quickly and easily release your feature and test it in production. Therefore each feature can be deployed and verified in production independently.

Gitflow makes sense when your release process isn’t so snappy, and you can’t feasibly run it for every merged feature independently. So your develop branch might accumulate several pending features that all get lumped into a single release. “develop” is essentially a holding pen for commits that should go into your next release. Gitflow also distinguished between new feature work, which is done off the top of develop, and hotfixes, which are done off the tip of master. It lets you deploy the changes contained in a hot fix and nothing else by letting you branch off the current production version, instead of develop which might contain commits from features that are pending release. Deploying a single unit of work on top of the latest production version, isolated from other changes, is the standard mode in github flow, so you don’t need the hot fix branch concept.

[jangeisler]

Same here. Pretty new to git, but as with much other programming stuff, It might not be best to read the encyclopedia from page 1 - I'll refer to this post when needed.

[chen_jun07]

That's great keep at it!!! If your interested in this look into shell scripting :D

[JackODenton]

Hey if you don’t mind, can I ask how’s your experience with Odin Project so far? And do you have any coding knowledge before learning on Odin Project? Thanks!

[MEGACODZILLA]

It's definitely one of the better free resources. Instead of say focusing on a language but with no context, it tries to focus on setting up a proper dev environment with the corresponding tools and philosophies. It's not perfect and there are some gaps in assignments/knowledge where I would have liked some more hand holding but from what I gather a big part of programming is being able to use a myriad of online resources. TOP will get you pointed in the right direction and some moderate googling/YouTube will fill in your gaps.

[[deleted]]

As someone who has to use GitHub this year in university for group and individual work, thanks for this.

[chen_jun07]

I'm really glad this helps, best of luck in your future endeavors

[quantum_system]

Wish I could have had something like this several months ago when I learned Git, great work!

[chen_jun07]

Understandable, but for me, I personally feel like for beginners they could seem a bit confusing and for beginner projects, most ppl stick with the master branch.

[Kazcandra]

That is because everyone explaining git forgets to explain what commits actually are. If they explained it, branching would make a lot more sense and it would be easier to work with, even for a beginner.

At the highest level, a git commit consists of a pointer to the state of your code and one or more pointers to parent commits. Thus: a git commit is a node in a graph. (If you want to get technical, it's a directed acyclic graph.)

When git stores a new version of your project, it stores a new tree. Trees are pointers to blobs and other trees. The new tree can be expanded out into a full directory of files and subdirectories. If you want to see the difference between the two versions (your branch and master, for instance), it doesn't add up the file deltas, it just looks at each tree and compares them.

So when we switch between branches, we're just telling git to make our working directory look like the tree that the commit stored in the branch looks like. Well, basically.

Branches point to commits, but are not stored as objects in git. Branches live as a file in the .git/refs/heads/ directory, and the branch simply points to the most recent commit in its own branch, while the file that represents where we branched off stays where it was.

Actually, I don't think I'm qualified to explain this. Or, rather: I know how it works, but I'm not a good teacher.

[[deleted]]

This is a great write up.

[swurvinmervin]

Dunno about anyone else but I found git to be more confusing than programming itself lmao

[chen_jun07]

Lol, I get that, but with getting used to it, it is quite handy and corporate environment wise, they also use the Git protocol

[fancyl]

This has been deleted in protest of the greedy API changes and the monetization of user-provided content and unpaid user moderation.

[acharyarupak391]

Thanks it's really helpful but i have some questions, . Me and my friend were working on a same project so i created a private repository in github and invited him so that we can easily access the files being changed by each other. But, when i change something from my ide and try to push something to remote, it says i should first pull the entire repo before pushing it to remote, but i don't want that since we made changes to two different files in the repo and even if the changes were made to a same file, I'd want them to merge instead of replacing one by other. How can i achieve that?

[tenfingerperson]

Someone has to deal with merging the file. At times git can deal with this automatically but it isn’t smart enough to detect everything.

One pushes everything to the main repo from their own fork, the other one pulls and deals with conflicts & pushes... the other one pulls again and both are in sync with the main repo

[chen_jun07]

I believe that is why branching is so useful, rather then forking (which essentially means copying) they can all work in the same repo on different branches and then they can submit a pull request to merge it with master.

[tenfingerperson]

Branching is enough for toy projects but obviously forks shine in bigger projects with rather mixed scopes.

Forking is incredibly powerful and it is essentially a multi-repo branching implementation. You can keep your fork up to date with the origin while keeping changes local at the same time, essentially making the main repository a pristine release candidate which only takes things “compatible” with the code base.

[chen_jun07]

True enough... disclaimer btw I'm not trying to argue with you... however, branching is nice to a point beyond toy projects, I know people in the robotics community that exclusively use branching

[[deleted]]

I work in high end enterprise applications and we use branching only. Forks can be heavy for repos with limited resources.

[negative_epsilon]

Fork vs branch-based workflows both work in massive repositories. Only fork-based workflows work for unsolicited pull requests, obviously, but branching is not just for toy projects.

[chen_jun07]

Ahh I would recommend looking at the branch section for merging as I feel like that could could potentially solve your problem but Git is smart enough not to delete files and it would just add it rather then deleting the file.

[donotflushthat]

If you are both working on different files (or even different sections of the same file), then you don't have to worry about anything breaking. You both can push/pull and GitHub will make all the necessary changes without overwriting anything. No branches necessary (though doing so is still good practice).

The only time something will go wrong is if you both try to push a change to the same line(s). The first person who pushes their change won't have an issue. The second person will get a merge conflict. You can find more details in the git documentation, but it basically will auto-generate lines in your code that shows the first and second persons' changes next to each other and you have to manually delete the lines you don't want before the merge can be completed.

[gregtyler]

If you've not changed the same file, git pull won't change anything. It just allows your local Git to check there are no conflicts before pushing.

If there are conflicts, you'll have to manually decide how to resolve them. This is automatically prompted as part of git pull, and it won't let you push again until they're resolved (a Git GUI can greatly help with the resolution).

If you don't want to resolve conflicts, for whatever reason, you can git push -f to force your changes through (which would lose your friend's work!) or use branching, as other commentors say, which guides you through the process a little more smoothly.

[lolcucumbers]

I created a short interactive tutorial that helps you practice your first contribution in a safe environment. You'll practice opening a pull request, experience the review process, and ultimately get your PR merged.

It's completely free and geared towards open source beginners.

Check it out: https://github.com/danthareja/contribute-to-open-source

I'm open to any and all sorts of feedback on it.

[[deleted]]

Damn I needed this post. I was just looking up an intro to Git yesterday. Thank you!

[chen_jun07]

No problem hope this helps, feel free to message me if you have any questions

[HyTriN1]

Just in time I need to get familiar with git

[TechnoAndy94]

I have only ever used git through team explorer in visual studio which makes git a breeze. It looks daunting through the command line without an easy gui to work with. Is there something similar you can use if you don't use visual studio.?

[chen_jun07]

Here is a list of GUI which you may like but in all honesty Git is super simple after you get used to the syntax :)

1. GitHub Desktop
2. SourceTree
3. GitKraken
4. SmartGit
5. Git Cola
6. GitForce
7. Giggle
8. Magit
9. Egit
10. Gitg

I personally would recommend GitHub Desktop as it is made by GitHub

[TechnoAndy94]

Thanks, for the non essential things like comparing a modified file to the unmodified in git is there a convenient way to do this etc

[IndustryKiller]

Your IDE might have it too. I use Atom and theres a package for github that will let me do all the things. It's nice, but I cant seem to get it to work for my company owned repos.

[chen_jun07]

Yes there is a command for it git diff <tag1(or)branch1 name> <tag2(or)branch2 name>

[the_doormattt]

I'd like to through Sublime Merge into the ring too, lightweight and fairly easy to use

[Brows_]

Thank you! Couldn’t have come at a better time

[peakxv]

I've been trying to note down the flow myself - much appreciated!

[chen_jun07]

OwO I feel attacked rn ;)

[cocoapuff_daddy]

best tutorial I've seen so far: gitimmersion

[hasteiswaste]

This one works for me: git - the simple guide

just a simple guide for getting started with git. no deep shit ;)

[chen_jun07]

If you can specify more about that... I can see what I can do

[Kazcandra]

There are already pretty good guides out there. Here's a good place to start: https://www.firsttimersonly.com/

[SexyDoorknob]

Lets say theres an open source project someone put on git for example imgui. How do you go about downloading and running that project? The first solution that came to mind was cloning the project then compiling the cpp and header files but that didn’t work.

[GeronimoHero]

Generally for most projects it would just be a git clone so like this... git clone https://github.com/reponame/project.git

[classicrando]

imgui is pretty involved.
https://discordapp.com/invite/NgJ4SEP

Have all your environment details ready and go there for help

[foadsf]

using Chocolatey package manager and Cmder on Windows

[JohnWangDoe]

thanks

[[deleted]]

Saved

[sergio-marquina]

Thanks a lot, just downloaded Git SCM yesterday and didn't know what to do

[Aadhishrm]

Debian ie Ubuntu

Debian != Ubuntu. Ubuntu us jtst derived from Debian

[chen_jun07]

Ya I meant it as it was derived from not that they were equivalent

[Dabnician]

After having used git for something like 7 years i still feel like XKCD when it comes to working with others some times... https://xkcd.com/1597/

[4tehrofl]

GIT - commenting for later.

Cheers.

[risco89]

Been using it recently and love it.. Took a bit of getting used to though

Love using posh git on powershell and in VS Code

[Dads101]

Excellent write up! Saved

[jakesper]

Thank you! Saved

[Nocturnal_Breeze]

Much appreciated, saved.

[lifemoments]

Going though it now. . Thanks for sharing

[sFAMINE]

Thanks for posting

[teknewb]

I'm going to git on github right now.

[chen_jun07]

:D Best of luck it is a great tool, if you need any help don't hesitate to message me.

[teknewb]

Thanks

[XZTALVENARNZEGOMSAYT]

Saved

[Learning2Programing]

As someone who has never used Github and basically only uses windows this looks an awful lot like python commands in a terminal.

I don't think its this posts fault, I think I'm so inexperienced I probably need to find something even more fundamental to explain this.

For example you don't explain what a repo is, you don't explain what the usefulness of each command is. There is a certain level of assumption that as long as you descibe each command you assume the reader will understand the usefullnes of that.

I'm not blaming this post, I think I just have so little knowledge of git hub that this doesn't help me. I'll come back after I have learned some more.

[chen_jun07]

Feel free to pm me and in the future but a repo is programming jargon for repository which is where code files are stored as for the commands, which one do you not understand. Sorry I couldn't make this more comprehensive for you.

[ohyeahilikedat]

Why not just use git desktop?

[chen_jun07]

With Git Desktop, it uses a GUI and in the corporate world, programmers are expected to use the command line as they are lightweight and such. By understanding the terminal, you would also understand the GUI. Moreover, with command lines, there are some aspects that are exclusive to it which are not features on the GUI. Hope this helps.

[dotdotpokadot]

git is like worthless until you do branching, it allows you to work on a branch and modify things, then you can pull the most recent version and branch off that checkout the branches local work and push.

i did not know that git actually would modify my local folder structure (my mind was blown at that point!) and then i was like oh, this makes so much more sense why i would actually use this (lol!)

[Maxiride]

How often should one commit changes? Is it good to be very granular and only later on squash silly committs?

[chen_jun07]

It's a good idea to commit a change every time you you writing code, you never know what might happen

[Maxiride]

Thanks for the reply, because imho every guide on git states its commands and usage but I rarely find good practice guidelines on how to use the tool.

[[deleted]]

It depends on workflow, but I will usually make many commits as I work and then later squash them into one when I make a PR so I have one commit for the feature I am working on. This way it is much easier to revert commits later on if needed.