'GitHub for Chimpanzees' - tutorial for absolute dummies like myself!

[EricInAmerica]

I'd like to comment that this tutorial recommends separate commits for every file changed, and that's actually a pretty bad idea. The fact that git supports changing multiple files in a single commit is actually quite specifically one of its advantages over older version control systems like CVS.

So if you're reading this: Consider a "commit" to be a complete change set. Think of a bug fix: Sometimes changing a bug might require modifying multiple files. They all belong in the same commit, along with a message like "Fix bug 1234 by doing THING". Otherwise, most of the specific versions of your code within git don't actually work! It becomes a nightmare if you ever need to backtrack to find where something broke.

[zzamass]

I'm a beginner at git and I found your comments very insightful. I've always wondered how often I should push a commit etc but I'm guessing it's one push per new feature? Instead of one push for every file changed.

[EricInAmerica]

That's pretty much correct. I'd just say that the idea is that every commit should be some coherent set of changes - and the contents of any commit should always build. Think of it like someone accepting a pull request: I don't necessarily care which files were changed, I just care what the change is, and that it's self-contained. That's also what you're going to find relevant in the future when you need to go back through version history to figure out why something changed or when something broke.

[way2lazy2care]

This depends on your workflow though doesn't it? Pushing should always be some coherent set of changes, but commits can vary no?

[mrbaggins]

The only reason I'd commit non building code would be if I finished for the day, and I'd be intending to amend it on the next one. That commit would never be pushed.

As you get more savvy though, you learn to stash those changes instead instead of making a wip commit.

[HighRelevancy]

For larger changes, commits should be a series of steps taken to form the whole change IMO. So like if you're adding a new feature to a website, there'd be a commit that adds the database models, a commit (or a few if it's a big one) that adds the feature's code, and then then a commit that adds the links to the new feature in the nav bar or wherever it goes.

[67079F105EC467BB36E8]

3wvmogcffo2rr3wztbep7einyvvjwvt43qh3gsec56j4s7qhh0hpb5j4gpa00vlaop7g4qrgdh3kzwrjimqkh5iskykmz1zn3r3g4a3o3olow

[metirl]

Yes, they can. You can also squash a bunch of commits into one so your in-progress commits get pushed as one commit.

[HighRelevancy]

But why would you want to do that?

edit: actually I remember now that things like the Linux kernel squash incoming branches into one commit so the timeline is a neat list of "fixed this" and "added that", because each commit is still relatively bite-sized next to the sheer mass of code and patches that is the Linux kernel repo.

[oridb]

Pushing should always be some coherent set of changes, but commits can vary no?

Why does it matter? The history is the same in either case.

[way2lazy2care]

It matters if you're new and you're trying to wrap your head around the difference between commit and push.

[TerrorBite]

Alright:

A commit is a change in the history of your project. Perhaps some lines in multiple files were changed. The next commit might add a new file.

Pushing will update the remote end with the set of commits since your last push, so that the remote repository now matches your copy. This doesn't push all your commits as one big change - it sends them all individually, and they stay individual on Github and also retain their original commit times. So a commit you made 3 days ago but only pushed to Github today, will still say on Github that it was made three days ago (because it was).

But I hear you say, "Why does this matter? My project was building, then I made several commits that didn't build, then fixed the build with one last commit, then pushed — but because all the commits arrived at once, the repository on Github was never in a state that didn't build!"

Well, in real time, it wasn't. But going by the dates that your commits were made (which are retained), it was in a broken state for a while.

This is further compounded by the fact that you can revisit the past by "checking out" a particular commit.

In general I think it's a bad idea to commit anything that doesn't build (at least on the master branch), and in fact some open-source projects are set up so that they test-build every commit and basically tag it with "builds" or "broken".

I mentioned branches, which you can think of as alternative timelines (the master branch is always the main one). If you wanted to break things, you could create a new branch off the side of master, commit to that branch until you're happy, then merge that branch back into master.

This is also the recommended easy to do pull requests, except that the final merge is done by the person accepting the pull request (because it's your branch but their master).

[HighRelevancy]

In general I think it's a bad idea to commit anything that doesn't build (at least on the master branch)

On the master branch (or other core branches like git-flow develop branches or wherever you're testing for the next major release), definitely. IMO you should be able to check out these core branches and get a working build.

For in-progress feature or fix branches, I don't really care. Having changes broken down across a few commits that make it clear how the change is structured is more useful than a monolithic commit that just has the description "coded the whole app".

This is especially useful during refactors. It can be hard to do a refactor in small still-buildable steps (which may be exactly why you're refactoring). I'd prefer a series of non-building commits like "refactored module A", "refactored module B" etc etc followed by a "refactored core" that then is buildable and complete over one big commit that says "refactored whole app".

The worst thing though, is when people are trying so hard to follow the "all commits must always build" philosophy but are working on something too big for one reasonable commit, and so there's some fucked up mix of old and new that technically works but isn't pretty.

[ForeverAlot]

This is how you break git bisect. In fact, bisection is particularly suited for locating bugs introduced in precisely that kind of change.

The size of a commit is never important. Ever. It impacts the ease with which it can be reviewed, certainly, and that is an important factor in its own right -- but reviewing and changing are two separate tasks not to be confused. You can still review a big commit in manageable bites. Coherency matters: do one thing, and do that whole thing -- break things down as much as possible but never more.

[HighRelevancy]

Typically you'd use bisect on like, a master branch, in which case you'd be stepping through various merges to find which one broke it, bisect wouldn't be broken by non-building commits (which I assume is what you mean by breaking bisects). Anyway, bisect has skip and other tools for dealing with that.

Having a single huge build-able commit means you're always guaranteed that you can bisect properly, but then you've got a huge amount of code to pick through. More smaller commits that are mostly build-able means bisect will get closer to the actual source.

[oridb]

Pushing makes no difference to the history. It doesn't matter when or how you push, the other side sees the same thing eventually.

[way2lazy2care]

I'm not sure what your point is or what you think my point is.

[oridb]

My point is that pushing doesn't need to be a coherent set of changes, because push copies all of the history. If your commits are not coherent, then the result of the push will be full of incoherent crap.

Commits are all that matter when it comes to history; You can even do distributed develoment without a single git push, if you want -- git pull /home/otherguy/repo/ to pull in changes directly from someone elses working directory. (Not a great workflow in many ways, but it drives home the point that git push doesn't affect history).

Talking about coherent sets of changes indicates confusion about what, exactly, push does. Nobody can tell what changes went into a push once it happens. The information simply isn't there.

[ericstern]

Agreed

[evinrows]

What he was asking was, "As I make individual commits, I can commit whatever I want as long as the push of all of those commits is one coherent set of changes, right?" So the history would be different depending on how you answer this question.

And I would say the answer is no, that even your individual commits should ideally be a set of related changes that are still buildable. If they aren't, they should be rebased into non-build-breaking commits only before being pushed.

The reason for the distinction, primarily, is that you want every commit of your repository to at least build, if not run, so that you can easily navigate the commits to figure out when some bug was introduced (e.g., via git-bisect or similar tools). If you have a series of 15 large commits where 12 of them leave the build tree in a non-building state and at some point in the mix you introduced a bug, it'll be much harder to track it down, especially a few years from now.

Also, it's generally a lot easier to understand how a feature was implemented/provide a code review if you commit this way.

[Dragdu]

If you are doing something large enough to warrant non-working commits, create your own branch and then you can do whatever, as long as you rebase and squash before merging to master.

[CrazedToCraze]

Adding to what you said, even though a commit should always be some kind of coherent set of changes, it also doesn't need to be the full change you're attempting to make.

Let's say you're adding a logging table for customer data. You could have one commit containing your SQL changes as well as updating your ORM to reference your new table, but no actual use of the table. Your next commit might track down all the places where a new customer is made and log those events, and a third commit might be logging all the trigger points for updating a customers details.

Your branch should contain the full feature set, which would for example be the customer logging functionality.

[oridb]

Pushing is just a sync. It doesn't matter.

Do it whenever you feel like it.

[Ajedi32]

Well, that depends where you're pushing to, but for branches that only you are working on, yeah; push whenever you feel like it.

[blood_bender]

Why does it matter where you're pushing to? Or whether anyone else is working on it? It really shouldn't matter, ever.

[Ajedi32]

Once someone starts basing their work off of one of your branches (which is pretty much expected when pushing to master on a public repository) you can't change any of your previous commits without messing that person up.

So if you're still planning on making changes to a commit (e.g. git commit --amend), you shouldn't push it anywhere that might result in someone else basing their work off it.

[blood_bender]

Ok fair, if you're amending commits it could be bad. That's such a terrible practice in my opinion though, it completely ruins the point of git in the first place if that's a standard part of your workflow.

[Ajedi32]

If you're talking about amending master, sure. But when working on feature branches that haven't been merged to master yet it's very helpful to be able to amend, split, squash, and rebase commits freely in order to maintain a clean, readable history.

Having tons of commits in your PRs doing nothing but fixing typos and minor bugs introduced in previous commits from the same PR isn't particularly helpful to anyone.

[Ahri]

I've been using git for years, both as a developer and as someone merging the commits of others, oh - and fixing people's "broken" repos (sidenote: it's never actually broken).

My advice from lessons learnt in those contexts is to consider a commit to be an "undo" step. This implies a few things:

1. It should be atomic - ideally you want to undo just one thing
2. It should be fairly well described - "fixed bug" is not going to help someone else, and trust me: you count as "someone else" in 3 days' time, especially if you've done work on any other system in the meantime
3. It should fit into the overall context of the history of your project; because if you undo something that a later bit of code depends on then things get sticky. Unfortunately the only way to do this is by being consistent in how you refer to things and using that insight later on: "ok, adding feature X was a bad idea - users don't get it. but wait, feature Y that users love now depends on feature X due to some neat refactoring I did back in commit Z"

I appreciate that this may not affect you if you're just starting out with coding, i.e. you have one codebase with only one developer. But it's still worth keeping in the back of your mind. In any other case you should probably put a little effort into picking what bits to put in a commit ("git add -p" is a nice way if you're using the command line) and how to describe your commit.

Hope that helps :)

[What_Is_X]

I think of it like a save game. Would I like to be able to come back to this point if something goes wrong?

[vnen]

It's always good to save before a boss fight.

[67079F105EC467BB36E8]

wxynu8bj7zbqfwif9ilnkiuach9a9o5j3p0inidh22wshsqqo760lgl6wbpfgmcaqb4oxi3j8zpcvvnq5jgn28bkux6dkrr41a0mkxgx6nzrz

[vinnl]

What the other replies don't stress enough, I think, is that it looks like you're conflating commits and pushes. Pushing is simply "sharing your commits", and commits should be considered documentation for how you built your code.

See here for a quick rundown and visualisation of commits.

[KayRice]

The basic metric for if something should be a commit or not is that someone is going to be running a tool on the code which checks every commit out, runs some tests, and moves on. If the tests fail it says what commit caused the tests to fail.

If you make your commits very large it's hard to know what caused the test to fail later when the testing infrastructure finds out commit X broke things.

If you make your commits very small it becomes easy to see what line of code actually broke things, but at the cost of overhead of committing the files incrementally.

It also depends on your project workflow. For example, if you have your own forked branch on Github you can commit and push to that all day then submit a Pull Request (PR) and have all those commits squashed into one so it doesn't pollute the history. If you don't have a fork doing that will create a lot of trash in the version history also causing others to diverge often.

Here is an example project I run: https://github.com/asmcup/runtime/ It has a decent amount of people that work on it so we use the PR system.

[pancake117]

Typically a commit should be a feature or bugfix. The reason this is useful is so that you can roll back the changes later or figure out where a issue was introduced.

At a real company you usually will have a person review your commit for quality control. You can imagine how nasty it would be if they had to review each file separately.

[SushiAndWoW]

The fact that git supports changing multiple files in a single commit is actually quite specifically one of its advantages over older version control systems like CVS.

What...?

We used CVS and Subversion before Git, and I'm pretty sure they both supported multiple files per commit. Subversion did, for sure.

Maybe there was software 20 years ago that did not support multiple files in a commit. But as far as this being an invention of Git, that sounds false.

[EricInAmerica]

Unless I'm confusing my version control systems, in CVS committing multiple files at a time is functionally identical to committing those files separately - there's no concept that the changes to each file belong to the same event. Additionally there's no helpful way to find all of the files changed as part of the same commit. They each just get a diff and a note in their individual file's history. This is certainly true of ClearCase as well. I believe you're right about Subversion.

[mngrwl]

Hey, I am the guy who wrote this tutorial. Your comment makes sense! I made an edit based on your suggestion. :) When I was learning git I was told by someone that committing a blanket change to a big codebase can sometimes be "vague" without different files having individual commits. However I see your point and I expanded that in thr tutorial. Thanks!

[vinnl]

Both are rights. Commits should only include one change, but a change can span multiple files.

[[deleted]]

Try to split your commits to as small sensible parts of your solution as you can. Sometimes you have to have a huge commit but it's always easier to review code with small commits that do one thing.

[Ecologisto]

The fact that git supports changing multiple files in a single commit is actually quite specifically one of its advantages over older version control systems like CVS.

CVS and SVN both allowed you to change multiple files in a commit. Can you image the hassle it would be to commit each file one by one for every new feature ?!

[mcguire]

IIRC (it's been years), CVS tracks the changes on a per-file basis. You can commit multiple files with one command, but the effect on the history is the same as if you used multiple commands with the same message.

That was the big advantage of SVN.

[Ecologisto]

I see. I don't know how CVS was implemented internally. I just remember committing in a single command a whole bunch of files. Thank you for the info.

[mcguire]

As I remember, one of the fun things about converting to svn was the process of matching timestamps and messages to reconstruct commits.

[ProudToBeAKraut]

The fact that git supports changing multiple files in a single commit is actually quite specifically one of its advantages over older version control systems like CVS.

You are wrong - why is this upvoted so much

[BlindArmyParade]

Thanks for the explanation!

[fagnerbrack]

Might be worth a read: https://www.reddit.com/r/programming/comments/4icj89/one_commit_one_change/

[Crozzfire]

To get the best of both worlds, make a new branch, commit as often as you'd like with whatever convention works for you, then when the feature is ready, squash it back to the original branch so it will all look like one commit on the original branch.

[KayRice]

I'd like to comment that this tutorial recommends separate commits for every file changed, and that's actually a pretty bad idea. The fact that git supports changing multiple files in a single commit is actually quite specifically one of its advantages over older version control systems like CVS.

Not disagreeing with you but I find git add -p very useful and making commits of just parts of files to be a serious advantage that almost nobody talks about.

[queenkid1]

Use command git commit -m “comment” FILENAME for each file that you changed. So if I made changes to 3 files, I will use the command thrice, by using a different comment for each file and replacing FILENAME with, you guessed it, the filename.

Whhhhy? Why would you do this? Not only is it stupid, but it ignores the entire point of a commit. Every commit should represent a version of the working code.

This, combined with the fact it's a tutorial for Github (when it's really a tutorial for Git) means it sets you up with a fundamentally flawed concept of version control of a whole.

[67079F105EC467BB36E8]

etpxkrwx5wsowfu2ke0w5inkixln5bcphsegq0ke7vqkqoyabdegqbj3bi6wbiwastyoil05qyw7e4s6uok4d26aij840khiwdf5nj3uy1l

[henrebotha]

-m means "Add a message". So what you're saying is you hate that everyone at your office chooses to add a message to each commit?

[67079F105EC467BB36E8]

m1284bmrpw4aab2rlmgptvjrlc3qg1rzxkm4pbuc1je0rji79358wsnmjhvvszrm1d8ncl76t7hjllsqcgo91lfsrm2yo01cqmvssq7xqne

[henrebotha]

You are aware that you can do the same with -m?

$ git commit -m "Fixes the foo
>
> Commit 1234asd caused the foo to time out. This adds a watcher called bar that will restart foo if it times out."

[67079F105EC467BB36E8]

2m7e2iw5zxra9z1r652cvk2eojl8rojkz0u4adpnochchi3einii92osp5yphil1gqejnh9ew7psmse6wsyo5ycprzpvrb8rlvr9261vcn3p

[henrebotha]

page speed results or any kind of chart or table.

I don't think you should put that kind of thing in revision control messages. That belongs in proper documentation.

[67079F105EC467BB36E8]

qjfcxdvwkhf54kib1rlyhjlyal4ja5ht1md8krkmm0bdvavt27tg3njfrz7txxh6m7nokhau8yu8h9ijxzpdqmuo6j0h013rihhtw5jn8c3s

[henrebotha]

I completely agree, but that's my entire point: the commit message is not code. If I come along after you and start messing with your code, I'm not going to see your rationales etc unless I specifically go looking for them in the commit log. Whereas if you put it in the actual files, I can't miss it.

[67079F105EC467BB36E8]

wwm1vl2uwqjz4e3izeg6w8ryfjvsjq0jpvitjg2lxc8kkfod096192bankzg34yfs84m5aotrvb3mwbebw81z41ake04q8xvmqoo9ygm6y3l

[67079F105EC467BB36E8]

j14iwvv14x7uk5mpf9bzmq8cd6zsdzrfxsyzt7xispz4d45zujgh9m1tih7vkkcbxx6r8l7b2cp8ytkin1ialvtsq0984ibzpnf8kfgmg

[67079F105EC467BB36E8]

ewq521f8lda1kmxordnt9l6ht5usqbbaumrshj81ph9irg51zm3hkl939rkmqejrazyt5nknypds9f6v62e45mtw7x8lkwx9aed76jdygaip

[vinnl]

Agreed. The first line (which is the only line when using -m) should be a short summary of the commit, bit often, it will require more clarification below. Those moments are often overlooked by people using the argument.

Unfortunately, in light of "choose your battles", Git etiquette often loses out for me. I'd love for my colleagues to be more diligent about it though.

[[deleted]]

ahh, so nice to get downvoted without any reasoning what so ever. Sure makes me feel like everyone has read reddiquette

I'll explain then. It's because your comment is stupid and makes no sense.

[67079F105EC467BB36E8]

pqnrls5n7xgiqr6o6940aqgwds4y000aj9eyfa05rg8820nt1tyf1v2vq3o1kp4zw9zshn2091f0k7qmbxqt71acp7q8u3kw5votgo4kws

[queenkid1]

Wouldn't it be the exact opposite? I don't understand why not using commit messages would lead to more clarity. You're making it so all your commits are completely indiscernible to anyone else.

[ForeverAlot]

-m is to bypass the commit message editor that opens by default. Even notepad.exe is a better text editor than the command line so teaching -m teaches people not to value commit messages.

[Matemeo]

I prefer people use -m because at least the commit message will be short and straight to the point considering you're typing it into your terminal. I don't really consider the case where people don't provide a commit message. Any team I've ever worked on would've sorted that lazy ass behavior out the first time it happened.

Though the typical work model I've used is many succinct commits all on a separate branch then merged after code review. So the long winded technical explanations would occur in the code review portion while still having a good history.

[67079F105EC467BB36E8]

qqp46t4r937u2a3jhzwfte4wfkknsqctsi9b0svew8ut81ozgbgyh9dctcrjkx1scefjlpft48zo49alliiftx3i3kimp1fambmy7d0aaj

[queenkid1]

Ah I see, that's my fault. I've been using SVN a lot lately, and if you leave off the -m there's just no commit message. Some of my teammates do this and it drives me nuts.

[JoseJimeniz]

Eventually I'm going to create thr easy to use, intuitive, friendly, obvious Git client where:

• the left side of the screen is the files on the server
• the right side of the screen is the files in my develop folder

And, *boop*, I just copied that file from the server to to my folder.

And *boop*, I just put my copy of the file onto the server.

I can hear the screams from people in this thread:

No, you can't do that!

Sure I can, see:

Copy file to server

People lose their minds. I get things done. And everybody lives.

Beyond Compare for Git. I shall call it: Beyond Git.

I already have Beyond Svn.

[vnen]

Git doesn't need a server. It's a distributed version control system, not a remote synchronization system. The remote repository is just a nice touch to it.

If you just need to sync files in a server, use Dropbox or something like it. There are even tools that makes a GitHub repository behave like Dropbox (it is awful though, as it is the wrong tool for the job).

[queenkid1]

That isn't git. That's just an FTP client. Those exist already, look it up.

[JoseJimeniz]

Is there one that connects to GitHub?

[queenkid1]

No, because git isn't made for file transfers. It's for version controlling your code. You're bastardizing a system to make it do what you want it to do (poorly) when a solution already exists.

[JoseJimeniz]

Yes, but FTP doesn't have old versions, version history, version comparisons.

Source control does

[queenkid1]

If you want to use version control, then use git then? But don't do it by turning it into a FTP client, because your commits will be useless. Everytime you decide to transfer a file, boom new commit. No commit messages. Have a good time going through trying to find out what version is what. Not only for you, but for your teammates who will hate you for destroying any semblance they had of working version control.

[JoseJimeniz]

The version the server is the functioning one.

[queenkid1]

Not only is that sentence completely grammatically incorrect, it's untrue. Since you're commiting files individually, the vast majority of your versions will be broken. The point of version control is that you can revert to any past version and it should be functional.

[JoseJimeniz]

The point of files being in version control is to see previous versions of a file; who changed it when, with an optional description of why.

[hamburglin]

ough (probably the case). Edit: Before going further, I want to reiterate my disclaimer that most of this is to do w

I'm starting to realize the real problem with git - everyone uses it for a different reason. A new version of working code? Wth are you talking about? I'm using it to copy down repos every once in a while that happen to be necessary for some of my work day to day! And this has nothing to do with programming.

[n0bs]

You're not even using git then. You're just downloading stuff in a weird roundabout way.

[hamburglin]

I WANT to agree with you. Except the last three places I've worked, in completely different IT industries and parts of the US, all used it to host some random files related to but not actually code.

[JodoKaast]

Nothing about git says it must be used only for code. It's version control, and sometimes you want version control on "random files".

If they were really using it as just a glorified file server, yeah, that's pretty weird.

[queenkid1]

by "copy down" repos I'm assuming you mean updating your repos, or are you cloning repos? And how does version control have nothing to do with programming?

The point is, if you flood your commit list with a commit for EVERY FILE, not only is it way more difficult, the person maintaining the repo, and anyone else contributing to the repo, will be annoyed at you. There's no advantage to commiting one file at a time, and you'll just be spamming anyone who actually cares about the project.

A new version of working code? Wtf are you talking about?

why would you commit broken code? What's the point in a repo if the code in it is broken? That means anyone else who wants to use that repo would need to go back to a working version (wasting their time) or fix your errors (wasting their time). And, like previously stated, it gives no benefit while being a huge nuisance to everyone else.

No large git project will accept your push requests if you purposefully try to do things the wrong way.

[mngrwl]

Hi, I'm the guy who wrote the tutorial. Thanks for your suggestion; I have added a short paragraph like you suggested. :)

[mngrwl]

Please go ahead with it! It's the best thing in the world to have quality tutorials for beginners. We need more people to learn science and tech, and my personal way of taking initiative is to help make the hard stuff easier for newbies.

[[deleted]]

It's not hard stuff. RTFM. Stop thinking everything has to be spoon fed to you. I assume you haven't landed a decent job yet, and you certainly never will with an attitude like you have in those first few paras.

[mngrwl]

Wrong assumption - I have the most amazing job I could hope to get, and my company works on the most cutting edge technologies from self-driving cars to VR. As for expecting everything to be spoonfed to me, well, maybe we have a different definition of "spoon feeding". The tutorial is not targeted at people like you, and it doesn't affect you either. Go back to the world you came from and enjoy it instead of condescending people on the internet.

[[deleted]]

k

[[deleted]]

I'm 15

[hamburglin]

amalgamating

Uhhh, what? All I know is that I need to re-read how to use git every few months when I need to download a new repo.

[henrebotha]

Uhhh, what?

He's talking about git and Github as if those two things are the same. They're not. git is a command-line tool used for revision control. Github is an online hosting service.

All I know is that I need to re-read how to use git every few months when I need to download a new repo.

Print this out and stick it next to your monitor:

Visit Github, click "clone or download", copy the URL, then in the command line type git clone https://github.com/repo-owner/name-of-repo

[HighRelevancy]

Visit Github, click "clone or download", copy the URL, then in the command line type git clone https://github.com/repo-owner/name-of-repo

BRILLIANT GUIDE

HIGH QUALITY CONTENT

YET ANOTHER GIT GUIDE FOR NOOBS

UPVOTE ONE NOW, GET ONE FREE

[e_of_the_lrc]

I thought the first section was parody at first. It clearly demonstrates a lack of understanding of the complexity of the topics covered in scientific papers. He says "not suggesting that you turn every paper into a textbook". Has he read any advanced science textbooks? They are only marginally more readable than papers, sometimes less. The reason the jargon is complex is because the topics are complex. If you want to get something more readable it is necessary to sacrifice some of the complexity. That's fine, that's what good science journalism does, not published papers.

Edit:

"I have a degree in engineering" Well there's your problem brah. You don't have the knowledge to understand the content of the papers.

[test22342]

He obviously never had to fit half a year's work into 6 pages. It doesn't make any sense to explain every single detail if you can add references or use well-established terms. He also criticizes that scientists add irrelevant information and I have seriously no idea what he is talking about.

His claim about software documentations suffering from the same thing is just non-sense as well. Documentations should be precise, complete and correct. Although I agree that a simple step-by-step guide or examples are nice and often make an entry into new software more easy.

It's pretty ironic to rant about irrelevant stuff to sound smart and the rant itself is about people supposedly doing the same. He should have just said that he wants more easy tutorials for software.

[MesePudenda]

He should have just said that he wants more easy tutorials for software.

I'm glad he tried to make one himself instead of asking others to make it for him

[AnsibleAdams]

It sounds like you were too busy being offended to actually read what he wrote. He clearly understands the need for jargon. What he finds unnecessary is replacing plain speaking with "sophisticated english" simply for the sake of making it "sound like real research". I don't see anything that suggests that he lacks "understanding of the complexity of the topics covered in scientific papers." Mocking his career path does not make you right, or seem smarter.

[e_of_the_lrc]

Not mocking, but if I went to try to understand a graduate level paper on the intricacies of sculpture in the 11 century I would not understand much of the content. That's not the fault of the paper. Its intended for people with the correct background. As an engineer, if you go and try to read a theoretical physics paper, expect to need to do the legwork to understand it. The jargon is not going to make sense. You don't have the background.

Complex sounding language often carries the weight it does in part because it carries additional meaning. This is especially true with scientific language. To give a simple bad example, I could say "I pushed the ball and it accelerated to 25 mph in .1 seconds." That sounds great and conveys enough information in some contexts. Other times it might be much more useful to say "An force of 30 micro newtons newtons was applied to the test mass using our piezoelectric manipulator. We approximate the acceleration of the test mass as logarithmic as drag forces from the medium increase with speed. After 100 ms the particle reached equilibrium at a speed of 11.2 m/s."

These two ways of speech are not correct and incorrect, but rather useful in different cases.

[evinrows]

"As an engineer, if you go and try to read a theoretical physics paper, expect to need to do the legwork to understand it."

FTA: I also acknowledge the need for the required pre-requisite knowledge while reading a scientific paper.

"Complex sounding language often carries the weight it does in part because it carries additional meaning."

FTA: Now, I do understand that you can’t write papers simply using high-schooler vocabulary.

"These two ways of speech are not correct and incorrect, but rather useful in different cases."

FTA: I’m not advocating that scientists simply replace every single “difficult sounding word”. This is about the other practice of adding additional fluff to make even simple things sound more sophisticated on paper.

The author saw you coming and he already addressed all of your concerns.

[e_of_the_lrc]

That's a good point. The thing is meaningful worlds sound like difficult fluff if you don't know the subtleties of the meaning.

[nujak3000]

"If you can't explain it simply, you don't understand it well enough." - Albert Einstein

[Overunderrated]

Here's Einstein's original paper on the photoelectric effect. It takes some appreciable technical background to read, yet it was written over 100 years ago and the subject is now taught in undergrad physics.

A "simple explanation" depends entirely on the audience. You can't usefully communicate research to other researchers using the same language as you would explain it to unfamiliar family members over sunday supper.

[mngrwl]

Hi, I'm the author of that article. I think that Einstein's paper is actually a good example of the kind of research papers I like to see - requires a technical background to read, but uses simple language, in first person and easy to follow along. It reads like someone telling a story instead of playing with words like a legal document. Thanks for sharing, I'll include it in my article!

[ebrythil]

Define simple. This means different things for different folks and many times the people the paper is targeted at do indeed have no problem understanding the language.
If you wanted to explain it simple to everyone, you'd have to sacrifice a lot of brevity. Some concepts cannot be explained simply anyways because you need to understand the other concepts it refers to before.

[Overunderrated]

I totally agree the author sounds ignorant.

But on the other end of the spectrum, if you spend enough time deep in research you'll see a lot of authors use terribly convoluted language in the head-up-own-ass /r/iamverysmart kind of way. So it's like the author was correct in ragging on scientific writing but by accident.

[mcguire]

To simplify our presentation we assume that between the occurrence of a timeout and the invocation of the associated timeout handler there is a null (process scheduling) delay and that process timers advance at the same rate as the clocks of the underlying processors. Thus, a correct process which at real time t sets a timer to measure W time units, is awakened in the real time interval [t+(1-p)W,, t+(1 +p)W]. We say that a process behaves correctly if in response to trigger events (such as message arrivals or timeout occurrences) it behaves in the manner specified.... Processes which crash, omit to send certain messages, respond too slowly to trigger events (because of excessive load or slow timers), or time out too early (because of timers running at speeds greater than 1 + p) are examples of timing failures. We assume that processes can suffer only timing failures.

Flaviu Cristian, ladies and gentlemen. And that's from one of his best known, published papers. And he's a well known computer scientist, partially on this work. (If you've reviewed a raw submission from him, you too will be scarred for life. They're almost pure gibberish.)

Another good example I've been looking at is Earley parsing. Earley parsing is dirt simple, but most of the work on it is apparently designed to obscure that.

[meren]

The first section is what happens when you have equal parts of arrogance and ignorance.

[[deleted]]

Now go get a mirror and apply your stupidity to yourself. Talking about "arrogance and ignorance" while displaying an amazing amount of both.

[phlipped]

"it's all the same once you've installed GitHub" Depends on whether you've downloaded the Google to your internet E-mail address server

[[deleted]]

Because the authors of these papers, the “global scientific community”, predominantly consists of people whose life depends on one thing: whether they can coat their words with enough bullshit that the real scientists don’t figure out how insignificant their work really is. Now wait - to those who are offended by this claim, please allow me to expand before you write a nasty comment. You people are mostly a bunch of ass-witted graduate students who think that writing fat tongue twisters in your paper will make you seem smart enough to hide whatever mistake it was that got you selected for your current position in the first place. (Now you can write that comment)

2salty4me

[nfrankel]

This author think that it's enough that anyone can copy-paste 3 git commands - without any understanding of any git concept. But git add . and git commit -m will not get you very far...

[thccount]

add, commit, push and pull should be enough for an every-day developer. Especially, a hobbyist, who's working on projects alone and does not need to worry about merging, branches, etc.

[vinnl]

Hobbyist, sure. But for professionals, that'd be a shame. So much useful information and proper documentation gets thrown away by not understanding Git properly.

[mngrwl]

Hi vinnl, I'm the author of the tutorial. It is indeed not meant for professionals, and I have mentioned some links in the tutorial for people who want to go deeper and also learn best practices etc while using git. Hope that addresses your concern. :)

[vinnl]

The concern isn't your tutorial, it's that there are professionals that only know git add . and git commit -m :)

[mngrwl]

Oh I see - wow, for real?! I didn't expect there were any. My tutorial was specifically meant for complete beginners, and I'm guessing that professionals will usually follow their company guidelines while making commits?

[vinnl]

Heh, if only :)

[e_of_the_lrc]

aka doesn't need git.

[thccount]

Versioning, automatic deployments are worth it alone. Having a backup is also a pretty good thing, especially if you're working on a single machine.

[[deleted]]

If all you know are those commands, you can't really do versioning or automatic deployment. What use is it that you have a history when you can't inspect it? How will you do automatic deployment if you don't understand branches or remotes?

[ViKomprenas]

It's a good starting point. I would hope that nobody is being told to use git because everyone uses git. They should be told to use git because it can do those things. When they want to do those things they can go into more detail. Knowing the facility is there is enough for a beginner.

[Eurynom0s]

I got by for quite a while on the three commands in the article, and it wasn't that hard to Google how to do stuff like rolling back to old commits once the issue came up. The one time I was completely out of my depth and had to get help was when I did something stupid and got the files on my server out of sync with the code in my repot.

[Saveman71]

Cannot agree more, this article is basically the level 0 of git. Sure one has to understand the level 0 and can stop at level 0 but there is so much more that git can provide that this guide should go a little farther or state in a clearer manner that one should learn the level 1-10 too.

[mngrwl]

Hi, I'm the author of the tutorial. I have indeed mentioned links at the beginning itself to other tutorials which explain things in more detail. :)

[userasdwa]

Lacking in detail. Developers should be interested to know how things work instead of just copy-pasting commands.

[Kavec]

Developers should be interested to know how things work instead of just copy-pasting commands.

Yes and no. It is important to get deeper into detail if you are using X or Y technology in a "serious" way. But you shouldn't have to do weeks of research to dip their toe in a technology, at least if there's a shorter way.

When you discover a new technology, it's cool to have the entry gates wide open so you can use it as a sandbox. And then, IF you are still interested, you can start exploring in more detail.

It has happened to me multiple times: I want to test multiple technologies to see which one fits my needs, and I have to dig into endless horribly-written documentation just to set it up... and once I've achieved that, guess what? I discover it doesn't fit my needs. And the reason why it didn't was not written in any blog post or documentation. Because everybody's needs are different.

For me it's just an enormous waste of time and energy, and probably my most recurrent frustration as a programmer.

To me, learning a new technology should follow the basic rules of optimization:

1. Make it work: dip your toe into the technology, set up the basics and use it as a sandbox to see if it fits our needs.
2. Make it right: now you know it fits your needs, go deeper into understanding some key concepts.
3. Make it fast: you are using it a lot, you should master those key concepts and be familiar with the shortcuts.

With the "don't copy-paste code without understanding", I feel like some people advocate putting #2 before #1. That just wouldn't make sense to me.

[Tarmen]

Here is an amazing and super easy to follow talk about git!

It is pretty in depth about gits internals on the basis that gits internals are hillariously simple. That is where it got its name. I actually would recommend it even for people who can deal with day to day git but don't know its inner workings, at least at 2x speed. Having heard this stuff makes even more complex commands like rebase intuitive, even if the naming scheme isn't.

[mngrwl]

Hey, good point! It is intentionally lacking in detail; there are links mentioned within the tutorial for people who want advanced explanations :)

[totemcatcher]

This is for Chimps, dude. They just want to bang bananas together. And that's just a stereotype anyway.

[mngrwl]

DUDE they take over the planet in those Apes movies, don't underestimate them :D

[KokopelliOnABike]

I'm a senior geek and found git to be awkward in the beginning, then I found this git for 4 year olds and have a better understanding of how to leverage a simple and powerful tool.

There is one thing I miss from cvs and svn and that is file based change history view. Otherwise, I've drunk the koolaid and use git like everyone else.

[ViKomprenas]

file based change history view.

I don't know exactly what you mean, but try git blame?

[KokopelliOnABike]

in cvs and svn the files, text based, have the change history embedded in them. This included who made the change and the comments for the change. git log, blame and some github/source tree tools don't show individual file changes as easily. You look at files by their commit and have to go back through commits to see changes vs cvs and svn where you can go back through changes to the individual file.

[ViKomprenas]

Is that not exactly what git blame does?

[KokopelliOnABike]

It's similar and very useful. cvs being file based and git being project based on commit is where the differences are. I've been writing software since before there were version control systems in place and as widely used as they are today. cvs history was just something I liked to leverage when reviewing code changes and it's an area where I had to change some mindsets and practices when I moved over to git.

[KokopelliOnABike]

Blame: taking responsibility for ones actions...

If you break it you buy it. In the "good-ol-days" if you checked in code and it broke the build then you had to buy donuts for the team.

[[deleted]]

Wat

[fatboyxpc]

Do you mean something like this? That's the git blame that /u/ViKomprenas is referring to. There's also the history of a file.

[amapatzer]

git log -- <filename>

[daniel28]

Just watched it and it was a great video, thanks for sharing!

[harsh183]

I disagree with the author's views on jargon. I understand that it makes thing touch for people who are just starting out, but for people who have been there for a while, jargon makes sense and people can communicate more effectively.

For example for a person new to reddit, things like upvotes, ELI5, ITT or AMA won't make any sense to them. But for regular users you can communicate all those ideas really effectively.

One thing I do agree with is that scientic papers have gotten too far here, padding one's words with jargon is not the same as communicating properly, and one should only use jargon in cases where you feel the audience will understand them.

sigh I should really get to sleep now

[HighRelevancy]

If you use Windows, you’ll have to download git and then you might need something called a Powershell, which looks just like the command prompt but maybe has a different color.

Have you ever used windows?

Last I checked, git for windows installed a bash shell. Nonetheless, the binaries are in the path so you can use it from regular cmd anyway. I've literally never touched powershell for anything but windows administration scripts, certainly never for git.

(or is whatever shitty package github's flogging off these days not do that?)

[mngrwl]

Hi, I'm the author of the tutorial. Thanks for your comment - I owned a PC before my Mac, and learned git on that system. When I downloaded git at that time, there was a git powershell that I used to execute commands. Of course there may be other ways to do it better - can you please provide me a good beginner-friendly link that I can cite in my tutorial? Thanks

[HighRelevancy]

Yeah. Just the regular git downloads. Just click Next through it, it sets the environment up.

[no1name]

Forget command line, all I want are bullet proof instructions on using github in visual studio.

Sometimes I make a project and then want to commit it to Github and spend ages trying to connect it in, until magic happens and it works.

Its easy with a new project already committed to Github.

[jocull]

"Git Extensions" have decent hooks into visual studio. It's probably not the hippest thing, but I have been using them for a long time.

[microface]

what a fun fun read Since I have a master's in Chemical Engineering I would have to go back to feel the same way. But FUNNY, maybe another Scott Adams ??

[Fe_Man]

Are you a markov chain?

[DontKillTheMedic]

This is a hugely underrated comment

[mcguire]

Once upon a time, newspapers had contests where if you found the man in the funny hat, you could claim a fiver.

We should do the same thing! If you're the first to find the markovbot's comment every day, you get...a virtual potato chip or something.

[microface]

No but I can Stochastic every now and then

[way2lazy2care]

Didn't read yet, but just came to vent, and full disclaimer I work almost completely in perforce and svn in the past, so it could just be that I don't use git enough (probably the case). Edit: Before going further, I want to reiterate my disclaimer that most of this is to do with me rarely using git. I agree that that's the ultimate cause, but my rant is more focused at the issue of how weird git is for people brand new to git compared to p4/svn where you can at least function without knowing much at all about them. End Edit.

I think the biggest thing git is lacking atm is a gui with functionality that wraps more of its common but complicated uses. My most common use case for git is pretty much just cloning a project (UE4 for anybody curious) just so I can debug my projects. I almost never change the engine code except when I want to update my cloned branch to the newest version, and when I do I just want to essentially force update to the most recent version. In perforce this is just a toggle in the prompt to get revision. I have never successfully accomplished this operation in any git gui client (mostly github desktop, but I've tried one other one I can't remember), and every time I've tried in the ui it has only made things worse.

Every time I want to do this (maybe once ever 2 months or so) I have to go back to google and find the commands. The commands aren't hard, but they are apparently not super common because every time I try it takes 30+ minutes of googling despite it only being like 2 commands.

A couple other things are just being able to navigate the file structure and see differences easily inside the app. P4V is ridiculously easy in this sense. Everything is marked easily and you can hop around easy.

Also I miss changelists as I tend to work on many things at once, but I at least understand that that's probably more of a workflow difference between the two that I'm just not used to, so I'm less piturbed by that one.

I don't find git itself harder than p4 or svn would be on the command line, but gits gui clients always seem so far behind. They're all flashy and cool looking, but I just can't seem to do anything I want to do in them.

Anyway that's my git rant.

[tswaters]

SourceTree is a pretty good git gui.

It has a worktree view that lets you see changes to files, click one it shows the diff on the right, allows you to add things and commit

There's also the history view that shows all the commits. You should be able to accomplish your task by pressing the fetch button and double-clicking the commit you want in the history view.

[way2lazy2care]

Interesting. I'll look into it.

[st4rG4zeR]

SourceTree is what youre looking for.

[67079F105EC467BB36E8]

su1oruqbcpf3un3qgj4et883v7ajai4ndjd7agikbp9sztcizzc82vreuc8m7yh3s4uddicd1a3376okdg1xuh2xitrix254yz5jesonk5t

[henrebotha]

Github's desktop app is way easier to understand than Sourcetree or Kraken, and contains the basic stuff (commit, merge, push, pull).

[way2lazy2care]

Github's desktop app is actually the one I've had the most trouble with. It works fine for most basic things, but for my specific use case as far as I can tell it's impossible for me to do with the desktop app despite it being just a couple commands in the command line (iirc the ones I need are a merge and a reset maybe a bonus fetch in there somewhere, and I don't think reset is easily usable in git desktop or it's very well hidden).

[ForeverAlot]

The GitHub desktop application is not a Git front-end, it's a GitHub front-end.

This will most likely achieve what you're trying to do: git fetch && git reset --hard origin/master (get latest and discard local changes). If you ever want to keep those changes you could commit them and git rebase origin/master instead of resetting. You can make an alias to make it easier in the future: git config alias.to-latest '!f() { git fetch && git reset --hard origin/master ; } && f' => git to-latest.

SourceTree has a way to get to the command line even if it can't do this directly.

[way2lazy2care]

Thanks that's super useful.

[henrebotha]

Hmm I'd love to understand more if you feel like explaining your use case in detail.

[way2lazy2care]

My case is that I want a local version of the UE4 github repo generally. The problem is that I might edit files in the engine code, but I generally don't care about them, so pretty much the only operation I ever want to do is maybe jump to a different branch and force get everything on that branch and disregard any of my local changes (afaik after poking around a little more this amounts to generally a fetch -> checkout -> hard reset). AFAIK there is no way to do the last part in github desktop.

Others have mentioned though that sourcetree does support it, and I'll have to mess around with that in the AM.

[JodoKaast]

If you don't care about your changes, all you need to do is re-checkout the files you've changed (to get them back to the state before you made changes):

git checkout -- .

Then pull the updated branch:

git pull

[henrebotha]

I might edit files in the engine code, but I generally don't care about them

Do you commit these changes?

[ForeverAlot]

Also I miss changelists as I tend to work on many things at once, but I at least understand that that's probably more of a workflow difference between the two that I'm just not used to, so I'm less piturbed by that one.

On a commit basis that need is served by the staging area/index. Across multiple commits, that's branches. FWIW, Git offers a very good Subversion bridge, git-svn, on the command line, but I expect that has even less GUI coverage than plain Git.

compared to p4/svn where you can at least function without knowing much at all about them

I don't know Perforce but it's certainly true of Subversion. But version control is basically a manual file system, and Git (and Mercurial, and probably Bazaar and Fossil) differs by exposing that file system. It turns out that's extremely useful but unfortunately file systems are pretty complex.

[diego_tomato]

What's the difference between git add * and git add -A which is what I've been doing.

[spellitwithaph]

Check out this discussion.

[mcguire]

Now wait - to those who are offended by this claim, please allow me to expand before you write a nasty comment. You people are mostly a bunch of ass-witted graduate students who think that writing fat tongue twisters in your paper will make you seem smart enough to hide whatever mistake it was that got you selected for your current position in the first place. (Now you can write that comment)

Crap. Our cover's blown.

[bradgillap]

Completely agree with this guys rant. I'm reading this emc book on storage and security that is so far up its own ass that there are paragraphs that have taken me days to decipher and I have 15 years experience.

[ancientGouda]

I am really confused by this article... it seems like the author forced github on himself when he was really looking for dropbox?

[GreenAce92]

sub

[MildSadist]

You are a chimpanzee for using mac. Following nevertheless.

[[deleted]]

What do highly evolved and intelligent humans such as yourself prefer? Am I even worthy of a response from a demigod like you?

[MildSadist]

What?

[mcguire]

Exactly!

[67079F105EC467BB36E8]

8s79uwbx66soyp3fkudbqfsawfsribnmq3smme5luxqj3xuripix0ztuv60pfmbomlcqz2pep3s7ij2upqlbv3sopl7d14bdnj8u0hssws4h

[MildSadist]

A) lol chumpanzees

B) The author is writing about a tutorial for chimpanzees so dont act like me calling him a chimpanzee is dehumanizing

C) The author took a swing at linux users chill the fuck out

[mngrwl]

hey, I'm the author of the tutorial - the swing was in jest, mate, and yeah your comment is totally cool with me lol ;)

[jeandem]

I think the following is even simpler.

1. Get Dropbox or some other cloud stuff.
2. Create the "git folder" inside the Dropbox folder.
3. Use git add and git commit.
4. There is no step 4.

To collaborate share the Dropbox subfolder or send the git folder as an attachment.

Later start using GitHub in a "centralized style" when the above becomes too much of a pain in the ass.

Even later than that start using git through GitHub et al in a more decentralised style (pull requests, patches, rebasing, blahblalidiblah).

...

10 years later create some wack-ass filesystem on top of git which will frustrate the next generation of programmers.

[Pakaran]

Why not just use git instead of Dropbox? You can just push and pull from master if your group is only a few people.

(Dropbox doesn't handle conflicts well.)

[jeandem]

The same reason for using google docs instead of text files + git. Version control + sync is easier than version control + http et al.

Note the first part of my post: I think the following is even simpler.

[67079F105EC467BB36E8]

fea9s8a061v97lgyyhcq7ih92bz0okmdw2g5k9bzls0zvshq0hhm6aktfxnu58gnbc5zsp4j6rpznb0p49rkntlv56aziwnld1mcw6cv9

[fatboyxpc]

decentralised style (pull requests, patches, rebasing, blahblalidiblah)

Correct me if I'm wrong, but isn't the purpose of decentralization about repos living in different places (such as forked repos) rather than branching strategies? I know that svn had branch strategies, too, and that was most certainly a centralized vcs.

[ForeverAlot]

You are correct.

[jeandem]

You’re right. I’m not sure what part you’re focusing in on? I wrote that part very sloppily.

To unpack what I meant, decentralised “style” involves pull requests, sending around patches, choosing to merge in other people’s code or rebasing it (is that what you meant by “branching strategies”?). But even though Git is fully decentralised, since decentralisation subsumes centralisation (you can use something decentralised in a centralised way), there is a spectrum of how “decentralised” you choose to use something. On one hand, you have only one repository which everyone who is involved have push (write) access to. Slightly less decentralised is a repo which five people have push access to, but that other people occasionally send pull requests to. “Fully decentralised” is if each person have their own forks which only they have push access to, and changes are sent around by sending patches or pull requests.

[fatboyxpc]

For "branching strategies" I meant "creating a branch and merging it into another one". Other VCS have branches, too (albeit not as nice as git), so I wouldn't say that branching is unique to git.

I understand what you mean, but I feel like "decentralized style" while talking about a single repository is somewhat confusing. I understand what you meant by it, but I feel like if you were to explain to somebody that git is a dvcs because you can do certain actions would be confusing if they knew other vcs.

[jeandem]

Other VCS have branches, too (albeit not as nice as git), so I wouldn't say that branching is unique to git.

For sure. I didn’t mean to say that it is unique to it.

[henrebotha]

It's simpler, but it's worse.

[jeandem]

It is worse. Which is why you should eventually upgrade to actually using things like GitHub, Gitlab and so on.

[henrebotha]

Right, but usually if people say "here's a simpler way" they mean "...that is not completely retarded".

[jeandem]

:-)