What is Reddit's opinion of
Git?
From 3.5 billion Reddit comments
100 reviews of this app found across Reddit:
A really good question, I'm going to throw out one answer. One of the most helpful things for the artist is being able to get their art in game without much hassle. If they're emailing you their spritesheets, and you're importing them into the engine, you've become a hoop to jump through. A much less painful process is to get regular developer builds to the artist, and as much as possible, allow them to be the first to run their art in game and iterate themselves. Being able to replace a spritesheet image with another spritesheet image, load the game, and see the changes immediately is how it ought to be.
Depending on the engine, this may be very straightforward, or rather complex. If it's complex, spend some dev time to create a pipeline that converts their assets into game ready formats, and write super-clear docs on how it can all integrate. And sometimes, there may absolutely require some much closer programmer/pixel artist collaboration, for example, with particle effects. Still, tools can help here too.
Ideally, and this sometimes isn't possible with the less technical members of the team, but teaching them the basics of code versioning software like git can automate the process of getting builds to the artists, and integrating art assets into the master build, smoothly.
In conclusion, what you really want to do is:
- Increase autonomy for the artists to do what they need to do.
- Allow the artists to iterate on the art themselves, before it gets to you.
- Automate close-to everything that can be automated, to make it less painful for everyone.
- Remove gatekeepers and hoops to jump through.
And often, a good set of well doc'd tools, and pipeline processes will tick those off. Have some conversations with your artist(s) and work out what needs to be built for everyone to be happy.
Part 4: About GitHub
GitHub, BitBucket, etc are all just sites/communities centered around using the program. They have some nice stuff but don't replace git or git knowhow. You can use git just as easily and effectively by copying the folder onto a flash drive or uploading a zip to Google Drive or something.
Part 5: Documentation and More Resources
Official documentation: http://git-scm.com/docs About git branching: http://pcottle.github.io/learnGitBranching/?demo
I think it's good habit to get into using git. Even as a beginner. Github is a server running git. You can use git on your local machine. You don't need github. Just know that your git/code/work is vulnerable to loss if its only on your computer. Github is one remote git repo option of many available.
To answer your question about multiple folders. Those are just file system folders. Its an organization of logical groupings of related files. Includes, images, etc..
Check out http://git-scm.com/ and especially the documentation. They break it down quite well from basics to working with multiple remotes and multiple coders in one codebase.
Git is a member project of the sfconservancy. So... Torvald's is at least involved insofar as he moved his project under their umbrella. You can verify that git is a member by looking at the bottom right corner of Git's official website
I've got good news and ~~bad~~ better news. (see second edit)
The good news is, if you've already run git add on the files, git will have added their contents as blobs to the object store, so the contents of the files still exist on disk (until they eventually get collected as garbage).
The bad news is, the data could be tough to find. I don't know of a good way to search the blob store. If you have a (very) small repository you may be able to find it manually though.
Here's an example of creating a new repository, adding a file and then retrieving it from the blob store:
$ git init Initialized empty Git repository in /Users/tpettersen/tmp/resurrect/.git/
$ echo "Test file" > test.txt
$ git add test.txt
$ git rm -f test.txt rm 'test.txt'
$ ls .git/objects/ 52 info pack
$ ls .git/objects/52 4acfffa760fd0b8c1de7cf001f8dd348b399d8
$ git show 524acfffa760fd0b8c1de7cf001f8dd348b399d8 Test file
Blobs (and trees & commits) are stored in the .git/objects directory. The first 2 characters of the object's SHA are used as the directory name and the remaining characters are the object's filename. The blobs themselves are in a binary format though, and I don't know a good way to search through them wholesale. There's some other great info on the object store in the Git internals section of pro-git.
edit:
Actually, you could run git fsck to get just the dangling blobs (blobs that aren't referenced by a tree/commit) your repository. If there aren't too many, you could manually check each of them using git show (or grep through them using a script).
double edit:
Here's a command that should print all of your dangling blobs (warning, there may be quite a bit of output depending on your repo's recent activity):
git fsck | grep 'dangling blob' | awk '{ system("git --no-pager show " $3) }'
I'm part of a "five people running two companies" team. Three of us do web design/development stuff. We use distributed version control on a local server that is mirrored to a backup on the Internets. It's not difficult to set up.
If you're getting money from people then odds are you're not stupid enough to not do something like this. Hence why I feel like this story is a fabrication.
You can use gitosis or gitolite for read/write permission control and git actually supports sparse checkout for partial checkout.
I think what you really want to know is how Git works, which is the version control system. GitHub is a website where you can store and share code (specifically made for use with Git), but Git is what really does everything. It keeps track of changes made, allows you to work on a separate branch that can be scrapped without affecting the main branch, or merged to keep the changes.
It doesn't really make a lot of sense until you actually use it on a project, but yes, it is a very good idea to learn it.
The Linux git workflow described by /u/catern is often referred to as dictator-and-Lieutenants-workflow.
I'm pretty sure the automatic functionality is built into plain git bisect, without having to gem install anything. I was actually going to comment the author missed the most helpful part of bisect – writing a script to return zero/nonzero if the commit is good/bad, then giving bisect a known-good and known-bad commit to search between. It does all the work for you.
Edit: see the section titled "Bisect run": http://git-scm.com/docs/git-bisect
Git is actually an open source product (no surprise since it's written by Linus), so you can run your on-premise absolutely free using this version.
Github is like the Redhat of Git
If you just want to get up and running, I think using a graphical approach is perfectly fine. It eases you into the concepts. If you want to see what's going on at the command line, do a "git log" or "git status" after you do things in the GUI.
SourceTree is a great graphical tool (which is also free) that is good at not hiding Git concepts from you as much as the others (e.g. the GitHub client.. that thing is terrible if you don't know what's going on under the hood). SourceTree will let you see your Working Copy separated out as files that you haven't staged yet, and files that you have staged. It'll also show you a history of your commits and different branches, when you get to that.
I think if you read the text based explanations first, it might be overwhelming if you just want a revision control system for your code. It might be good to get used to the terminology first with a GUI walking you through it.
That being said, this online book is a great resource for the concepts that also has command line examples in it: http://git-scm.com/book
Don't call the tool broken because you didn't read the manual. Submodules are for linking a version of your project to a specific version of another project/library. If you have to edit both projects in tandem they're probably too tightly coupled and should have been in the same repository to begin with.
Go read the manual if you don't understand something. Don't call it broken just because it doesn't work the way you're trying to use it. Git is working the way it was designed to work, and people that bothered to RTFM are getting work done with submodules without issue.
> Who the fuck is downvoting this?
People, who think pull request is easy enough to google?
Also, your description was not only gibberish but also partly wrong/incomplete: the term pull request might have been coined by GitHub (or rather its meaning was extended) but the concept works for pretty much every VCS. A local branch is not the local version of the project. Commonly you'd refer to it as fork (local doesn't really apply here). And I think even on GitHub you're free to choose any branch and even any commit you like to include it in your pull request. Googling for Git basics won't bring you any explanation of what a pull request is because it's not a core concept of Git and to my knowledge Git itself doesn't have any actual implementation that makes pull requests work automatically like on GitHub.
A ghetto solution might be to use the Git version control software. You can get the Windows version here.
Whenever I mod a game and run a chance of things getting messy, I go to the game's install folder, right-click in Windows Explorer and hit 'Git Bash'. Then I do something along the lines of:
git init git add . git commit -m Init git tag pristine
In simplified terms, this creates and stores a complete copy of everything in the directory, and it may be reverted to at any time. The 'add' phase may take a while at first, depending on the total size of the game's files.
Then I mod to my heart's content, and when I've reached a state where I'm happy with my modding, or it's just the right time to create a snapshot, I do something like this:
git status # just to check what's different git add . git commit -a -m 'blah blah mod mod blah blah cats'
So now I've got two snapshots of the game's directory. And if I ever wanted to revert back to my pristine state, I could do something like:
git checkout pristine git status # for posterity's sake
And if I wanted to go back to the latest state of my modding:
git checkout master
Running git log may also be useful. I'd recommend looking at the Git's site and reading its documentation.
Anyway, using the command-line and learning how to use Git might be overkill for something like this (Git has a learning curve, but it's a powerful tool once mastered), but that's how I personally deal with potentially-messy modding for games. It's worked pretty well for me and my lazy ass.
Nu, nu esti ultimul om. Versiunea ELI5.
- Mai stii cand te apucai sa modifici/testezi niste fisiere la un proiect, dar faceai un backup inainte, iar la un moment dat incepea sa devina frustrant ca xxl.php avea vreo 3 versiuni denumite xxl_ok.php sau xxl_aproape_gata.php?
Ei, git-ul te scuteste de asta, intrucat poti sa revii la versiunile initiale ale fisierului cand nu-ti ies socotelile.
- Mai stii cand mai lucrai cu cineva si cand faceai o modificare, trebuia sa-i dai mesaj aluia sa-i zici la ce linie ai modificat ca sa nu-ti suprascrie modificarile tale?
Ei, aici iar te ajuta, intrucat isi va da silinta sa impace snapshot-ul proiectului tau cu snapshot-ul proiectului lui, pana la un eventual conflict. In plus, daca nu are chef de consola si aveti interfata web, colegul va putea vedea singur ce ai facut.
Edit: Hai pe /r/robyte
I'm not sure what you're expecting to hear. I'm not being sarcastic. There are a lot of git workflow articles out there on the web precisely because this type of situation is difficult to navigate. They don't explain how to do it so much as lay out a way to use git that doesn't result in a situation like this. Here are three.
While git has a lot of open functionality, if you have comitted something once you can almost always get it back to that state. I don't understand how so many people have such issues with git. Might I suggest reading the free book that contains everything you will need to know outside of very abnormal operations? The book isn't that big and it will help you tremendously.
Also, there is /r/git for any questions you may have.
You're running Windows 7 on a VPS?
To answer your question, Windows has no native SSH support, which is how remote Git repos are usually accessed (outside of github). So people don't build Git servers to run on Windows.
http://git-scm.com/book/en/Git-on-the-Server-The-Protocols
If you really want to do it, install OpenSSH for windows and then anyone can access the git repos on the VPS via SSH.
Side note: I've installed GitLab on Ubuntu several times. It's really easy. If you can get an Ubuntu VPS it will probably work a lot better and be a lot easier to maintain, plus tons of extra functionality similar to github. An Ubuntu VPS with 1 gig of ram is really cheap to rent per month.
Good luck.
Pro Git is the best I have ever found and reading it has started to make me the "go to git guy" at my company, which is kinda neat. You can get a hard copy on Amazon, but it's free here for download (pdf + ebook) or web-based. I also have "Git in the Trenches" on my Kindle and while I've only gotten through some of it so far but it's pretty good - attempting to make a narrative and teach by example.
Some feedback:
You shouldn't be committing files ending with a ~, these are backup files made by vi. Add them to a gitignore (just *~ should suffice).
Also, the Reddit API seems to limit the max number of comments per request to 100 meaning that the PRAW API is (internally) making multiple requests to the api in order to get all of the comments (requesting 1-100, than 101-200, ...). I suspect this is what is slowing down the program since each request likely takes somewhere in the order of 100s of milliseconds to seconds. You can speed up this process using multithreading. Think about it like this: You and your friend go to a restaurant; now would you rather place an order for first yourself, wait for that order to be completed, and than place an order for your friend or would you rather place both the orders at once? Which one is likely to get your food first? It is likely that the second way will get all the food faster. It is the same thing with the Reddit API, if you place all your requests at once, you are likely to get them back faster.
Now PRAW's API internally doesn't do this for you. If you look here it is doing a standard loop to sequentially grab the data (It isn;t even requesting the max of 100 meaning it has to make 1000 / 25 (25 is the default comment limit) = 40 requests). It might be more work but you should investigate python's threading modules to speed up getting the data.
Feel free to ask any questions, and congratulations on your first web app! :)
If you start using it on your own project(s) you'll learn the basics and intermediate stuff pretty easily. The tutorials on try.github.io and documentation of the theory on the git-scm.com website are pretty straightforward. You wouldn't need a group to learn Git.
Git is hard. It's easy to want to compare it to another VCS and to mentally map concepts. But don't, because they won't map.
How long have you been at it? It took me a few weeks before I was really comfortable. Now I've been using it for 6 years and it's as second-nature as tying my shoe.
What client are you using? While it does increase the learning curve, I highly recommend getting super comfortable with the CLI before using any GUI. As most GUIs are just wrappers around Git commands, it's important to understand those commands.
Have you read this book? If not, I highly recommend it as it dives deep into the core concepts of Git. It was while reading this book that I got my first "ah ha!" moment.
Don't give up!
It doesn't just mean that you can read it, but that everyone can. A big premise behind advocating open source is that with enough eyes on the code, no one can tamper with anything without it being noticed.
And it's working. I've seen many times over the years someone try to whisk their code (good or bad) past everyone and get it into a project, only to be met with a huge amount of resistance. Code in these projects is versioned (see VCS) and all changes are backed up and recorded. It's a big process to get your code in these things, and none of it goes unchecked. Remember that open source doesn't mean that just anyone can change the (official) code.
And while the larger acceptance that the code is secure is built around trust, it doesn't earn that without continuously rigorous proof. Beyond the devs' concerns, many major institutions and industries internationally rely on Linux, and there is a highly vested interest for them to ensure the same concerns you have don't exist.
Absolutely. This is where leveraging the power of git's hooking comes into play. Depending on your acumen for scripting, you can use a third-party program such as gitolite or do it yourself.
The way I handle this at my shop is by employing the power of the update hook and user groups. This works for my flow, as my junior devs can push to ticket-based branches, then when signed off, are pulled into scoped branches by senior devs. This allows me to create a file in each repo called allowed-groups, where groups are given permissions to update certain git refs. It looks like this:
refs/heads/T[0-9].* junior senior refs/.* senior
Using regex, what this means is for branches that match the pattern T<number> (which correspond to our ticketing system), users in the junior and senior group have update access, and the next line gives senior devs the ability to push everywhere (including tags).
As per the docs on the update hook: >this script takes three arguments: the name of the reference (branch), the SHA-1 that reference pointed to before the push, and the SHA-1 the user is trying to push Leveraging this, I check against the allowed-groups file to verify access.
You can apply my approach for your person -> branch, as well as expand it to include deeper ~~searching~~ diff'ing against the ~~commits~~ starting and ending commit hashes with the flag name-only for users who are bound to directories.
E: clarity
Limiting what paths a user can modify can be done with a pre-receive hook on the server, and actually happens to be the example that the book uses: http://git-scm.com/book/en/v2/Customizing-Git-An-Example-Git-Enforced-Policy
Limiting read access is the part that's inherently not really doable short of slicing out subrepos for them.
> I want to be able to have every file have an "init commit" message next to it on github, but some of my files have messages from previous commits I did.
That's a bad idea, don't try to do that. A commit does capture the full state of every file, so you can see all the files as they were for that commit by clicking on the commit message and then clicking the Browse Code button. GitHub choosing to show the message from the last commit that changed the file is just a display issue. You shouldn't do unusual things like modifying every file just to make the display look the way you want on GitHub.
You should make a tag using Git (also see this SO question).
See: git-scm.com/doc
My understanding:
Say you're working on a project called "FOO". There are a bunch of files on your computer that are part of FOO. You are regularly adding files, deleting files, and updating files.
Occasionally, you make mistakes. Delete something you shouldn't have, or make a change that causes more problems than it solves.
A good backup system can help you recover from those mistakes. But what if you are collaborating with others on FOO? And what if you want to work on FOO from multiple locations?
And, what if you don't want to clutter up FOO's files with your half-baked ideas that really aren't ready to be shared with your collaborators?
That's when you might use git. With git you create a master bundle that contains all of FOO's files, and all versions of those files. People also working on FOO pull down that bundle, and push up any new versions of FOO's files that they are ready to share. You can then pull down any and all updated files, and not have to worry that you're working on some out-dated version of FOO.
In short: with git you can collaborate on a collection of files that are version-controlled.
Also, when you want to know who changed what, git has tools for that. When two people push updates to the same file, git has tools to help you merge the updates.
It should be noted, though, all of these tools within git are geared for plain-text files. It is a tool aimed at people writing code. While you can use git for versioned collaboration of any sort of file, the merging and conflict-resolution tools aren't going to be of much use for non-plain-text files.
Almost every action in git repo can be reverted. Read about git reflog and git reset commands.
This may be helpful too: http://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery
You mentioned using Subversion. If you're really sure you want to stick with that, Github does support SVN.
If you'd prefer to learn Git (which I recommend), you really need to forget a lot of SVN stuff you know. There's quite a lot of differences between Git and SVN. Attempting to apply past knowledge will just hurt you. You can't try and do something like "how do I do the equivalent of X in SVN". You need actually learn Git.
Read chapters 1 - 3 and 6 of <em>the</em> book. Don't bother reading the whole thing (at least not yet). That's experts only. First 2 chapters are a must. Chapter 3 is a very good to know (particularly to be able to use Git well and to understand what makes it good). Chapter 6 is specifically for Github, which is good to know (a must if you intent to participate in other people's projects on Github).
git reset --hard HEAD~ is one of the very few git commands that actually rewrites history. that is, a pointer to the pre-reset code won't exist, and you won't be able to access it through normal means. You CAN use
git reflog
to look at where HEAD has previously pointed and checkout that hash. but if you lose your reflog, your changes are gone forever.
This is opposed to
git revert <reference0> <reference1> <reference...><reference100>
that will actually create a new commit, with the changes from your <references> removed.
Edit: this is THE best explanation of git reset
A great writeup about a feature not talked about much.
With respect to encrypting your repository's contents, you also may be interested in using git's smudge/clean filters to automatically encrypt the contents of your blobs when added to the object database. Unlike the approach taken in the article, this would not encrypt the file names.
An example being: https://github.com/sufianrhazi/cryptogit
Git is a source control system originally designed by Linus Torvalds (the guy who created Linux). It is distributed and has a bunch of other keywords.
Where it helps writing:
- If you work on both a laptop and a computer (and you have a good file format), you can write on both and have it integrate the changes.
- You can create a "branch" for every project and switch between them easily.
- You can try an idea in a separate branch and, if it works, pull it in.
- You can tag points in time. For example, when I sent out a beta reader or editor request, I tag it. Then, when I get feedback, I can integrate the changes at that point, then apply all the changes I made while waiting for them to get back.
- Makes it really hard to accidentally blow away your work.
- It keeps track of your history, so if you know you wrote something but deleted it later, you might be able to go back and recover it.
First things first, source control. Use Git, and an online repository, like BitBucket. Never send code to each other outside of it.
To get around path differences, builds, and personal IDE settings, etc, add them to the ignore file. Here's a handy tool.
Might seem cumbersome to set up at first, but source control is the better way for teams to work on projects (and even solo), and is the way the industry works. You can even both work on the same source file and merge them together, can even include all binary files like art and other assets.
Lets take a step back and get a quick overview here.
Git is a tool for helping you manage your source code. It has an awful lot of features, and there are a lot of tools built around it. It is not a code editor. There are guis that come with it/are build for it, but they're optional. Most tutorials etc you find on the web are going to assume you're using it in a terminal.
GitHub is a website that makes it easy for you to share your code with others. It is built on top of git. Git includes ways to communicate with other systems to share source code in a managed fashion. GitHub, in addition to its web-based service, offers a tool (confusingly also called GitHub) that you can use as a gui for managing git locally, and for moving your source code from your local machine up to the GitHub service.
You also presumably have some kind of code editor, like xcode or textmate. This is the program that you use to write your software. Many of them have places in their interface for communicating with git.
It is entirely possible to use git without using GitHub. You can use git without having any integration with your editor of choice. The preferred way to deal with git is by typing commands into a Terminal.app session.
I suggest that rather than screwing around with the GitHub Mac Application, you instead open a terminal and start there. There are quite a few tutorials around the web to introduce you to the basics of git. This is the one I usually recommend.
If you are looking for something GUI based, try SmartGit/Hg (needs JRE):
http://tuxdiary.com/2013/10/22/smartgithg/
My personal choice is the lightweight QGit & Diffuse combo:
http://tuxdiary.com/2014/02/25/qgit-diffuse/
More here: http://git-scm.com/download/gui/linux
Yeah, it's hard to diff editions of a book. :) There are probably some sentences that we didn't change, but not very many. Most of that is corrections and updates.
The chapters on GitHub and embedded Git (Libgit2 and JGit) are entirely new, though. We also added content about two-way bridges and migration to other VCSes, graphical clients, shell integration, and lots more.
Oh, and if you've never really grokked "reset", have a look at this section.
At a conceptual level, git doesn't compress anything. It runs your file through the hash algorithm to get a 40-byte hex string unique to its contents, then stores the contents in your projects .git/objects under that hash (i.e. it makes a file named that hash, and puts the contents of the file in there).
At a practical level, though, as an optimization, git zlib compresses those contents, so you can't just open that file and read it. Zlib is the algorithm used in the zip format, so git actually does zip everything under the hood. You don't need to do it, and it would just cause more work for you.
Git has a further optimization: packfiles. In the objects directory is a pack directory. It starts out empty, and as you begin working in a repo there's nothing in pack. Eventually git will decide to optimize by packing all of the loose objects into a packfile in the pack directory in a packfile. You can do this manually at any point with git gc. Also, whenever you push objects, or fetch/pull them, they're packed up in a packfile for sending, and they aren't unpacked on the other end. Git can use its own packfile format natively and expediently.
Read the packfiles section of the Git Pro book - it goes over these things, and talks about gits compression of a large (12k) text file.
First, I'd like to ask if you understand anything about Git or other version control systems. If not, read this.
It's hard to fix bugs on someone else's code if you don't really understand it. I'd rather recommend you to keep using an open-source app (specially one you use often) and try to think of small and easy-to-implement things you'd do to improve your experience with that particular application. Then, try to modify the code to reflect your ideas and submit it for approval. By the way, don't forget to use best coding practices.
Presumably once cloned, the OP shouldn't need to pull from the template repo again, so she might-could do:
git remote set-url origin <new-url>
This is going to be more "my recommendations", rather than "widely-accepted community recommendations". Just to be clear. :)
First off, you don't need -a on git-commit if you've already added things to the staging index; it's redundant. Secondly, you should rarely use the -m option, as it strongly discourages well-formed commit messages.
I usually have untracked files hanging out in my working directory that I don't want to commit, so rather than using git add . I use git add -u, or sometimes git add -p; if I'm adding new files, I manually specify them (liberally using shell globs and expansions to avoid typing too much). Then I run git status to make sure the set of files is what I want (and I'm on the right branch), git diff --cached to make sure I've staged the appropriate diff and didn't leave in any TODOs, etc., and then git commit.
To summarize:
[$]> git add -u [$]> git status [$]> git diff --cached [$]> git commit [$]> git push
I have git aliases set up to make these common commands a bit shorter.
I would strongly suggest you give yourself an introduction to version control. If you plan to work anywhere with multiple developers you're going to need to know how to work collaboratively on a project. It's not hard, it just takes a little bit of practice getting used to the flow.
Take a look at the Git website, and make yourself an account at Github and start storing your code there. Not only is it a great place to backup your code, but also a great place to direct potential employers.
OS - Debian Stable? Ubuntu Server? Fedora? CentOS?
Just go with one of the big ones and you'll be fine, but do not go with a distro like Arch on a server (i.e. with rolling releases). I made that decision, and I'm really regetting it now.
Also, why not setup your own version control server on the machine (mercurial, git or whatever), and a bug/project management tool such as Trac.
Then of course setup samba/NFS shares, and you will definitely need SSH.
Reddit's source code is hosted on Github. With git, every object is named with a hash value. When you make a commit, the commit object has a hash that uniquely identifies it. The commit that introduced this change has a hash value of 4d7a2fa4e0f01f7010e0f7fd0317cb783cda54c1.
https://github.com/reddit/reddit/commit/4d7a2fa4e0f01f7010e0f7fd0317cb783cda54c1
See http://git-scm.com/documentation if you want more information.
The subreddit sidebar has a few. Pro Git, the top on the list, is pretty much the best reference in my opinion. The name sounds intimidating, but it starts from basics, it's not meant to only be for advanced users.
BTW, avoid stuff written on Medium. Chances are it will be rubbish.
There's a web tutorial that walks you through basic usage, documentation to explain more about what git's all about and how to download/install it, and links for those downloads. I recommend a combination of reading through the documentation and playing with the tutorial (and in general, application of google-fu to any questions of the form "How do I do X in git?" - whatever it is, someone's had that problem before, and if they haven't you should probably reconsider whether it's actually a sensible thing to try to do).
Github will give you some space for an online repository, but you'll still need to setup git on your own computer to run the commands locally and talk to their server. You don't strictly speaking need github involved; either way you'll end up with a local repository on your own machine. The remote repo is optional (but potentially useful as a backup, or if you want to work from multiple machines or with collaborators)
First of all, great work. Keep coding, keep learning! Don't let anyone bring down what you've done here. At the bare minimum, you've learned more node code and made yourself a better developer.
Now, as for feedback, I suggest taking a look at git aliases.
For example your code:
gg c Updated example in README
is written the same in native git as
git commit -am "Update example in README"
With git aliases, you can set ci to be short for commit. This is what most people do. For example, the above would simplify to:
git ci -am "Update example in README"
Either way, good work and keep working on it! Also, check out git extras.
Bests :)
Yes, for example gitolite supports per repository, branch and tag (ref) R/W access control as well as restrictions on specific files or folders
>Counting objects: 8, done.
Git counts 8 objects for transfer, this is most everything under git. Commits, tags, etc.
>Delta compression using up to 24 threads. >Compressing objects: 100% (6/6), done.
Git is compressing the objects, 6/6 is the progress of the compression in KiB
>Writing objects: 100% (6/6), 2.69 KiB | 0 bytes/s, done.
Git is sending and writing those objects remotely. 6/6 is again the KiB. Speed is shown as 0 bytes/s because it is completed (no more to transfer).
>Total 6 (delta 3), reused 0 (delta 0)
This is more obscure, and has to do with packfiles. It has something to do with its storing old unused object data, and checking to see if any of it can be utilized for the current setup.
>To <removed git repo address>
Where it is sending, but you probably figured that part out.
> 86755a1..380b5f0 master -> master
Updating remote branch master from commit hash 86755a1 to new (your local) commit hash 380b5f0
No. Git stores multiple similar files in what are known as pack-files. These basically store one copy of the full file, with a linked-list-like structure. Conceptually, think of it as:
v3_hash -> v2_hash, diff2_hash -> v1_hash, diff1_hash
So, to get the most recent version of a particular file, the blob object is fetched directly from the v3_hash. If you checkout a commit with an older version of the file (say v2_hash), it'll first grab the blob from the v3_hash, then it'll grab the diff listing on that file from the diff2_hash, and apply the diff to the blob returned from v3_hash.
note: this is a gross simplification. I'm not actually very clear on the format of a pack-file, and I don't have an exact understanding of how it all works, but this is the general idea.
See Pro Git: Packfiles for a better explaination.
I don't know why you'd need more than the (quasi-) official git book: http://git-scm.com/book
Its visuals are great for understanding what is actually happening at a data structure level when you are doing basic branching and merging operations.
You can. http://git-scm.com/blog/2010/03/10/bundles.html talkes about a way you might go about that.
However, since you're talking about binary files, you may want to consider something less fully-featured. Git is fantastic software for tracking text files, but it's actually not great at binary files like images. If you just want a backup and you don't need versioning, then a tool like rsync may be a better fit. It still only transfers the changes since you last ran it, but it also has easy resume support for if your connection times out, and you don't have to do three steps to get your data to the server (add+commit+push), it's just a single command.
GitHub is a Distriuted Version Control System (DVCS). It hosts git repositories.
A code repository is where you keep your code versioned. For example, you have been working for a while on your program, and you want to keep a stable snapshot so if you mess up, you can always go back. Without this snapshot, you'd have to go throughout the files you modified and revert all the changes, perhaps missing some. If you have the snapshot (called a "commit"), you just roll back to your commit and any and all uncommitted changes are reverted.
You can say, you could just copy-paste your code folder somewhere else, do your changes and if you mess up, copy the original folder back? Yes, but that's clumsy and tedious. Also, what if you're working in a team and two people modify the same file? How would you know who did what? Git helps with these issues, through features such as branching where different people have different branches of the project, work on it, do their commits and then merge branches at some points to bring their features into the main program.
With Git (the software), everyone has their own local repository and GitHub (the website) is the remote repository where everybody puts the stuff they want others to access. So they do local commits and when they're satisfied, they clean up their side and pushes their commits online to GitHub to allow others to access their work. As long as they don't push, their code remains on their computer. That's the distributed part.
If you want to learn more about Git, I would recommend this resource.
Read through every section here. Each section is pretty short and quick. Be sure to make test repos to try out each thing and to simulate how things would work in a group environment. A few things of note to pay close attention to:
- Rebasing - Understand exactly what it is, how it is helpful, and maintaining a clean repository.
- How to abort out of conflict resolution modes - At first this can be very scary, and knowing how to cancel and know what state you will be in is a huge relief
- Reflog - Many git users I know do not use the reflog to their advantage. Think of it as a safety net that you can use to go back to almost any point in time. Especially helpful if you do something wrong and think you lost a bunch of commits and work. Once you understand the reflog, and revert, you won't be scared to do a single thing in git.
> But my Martian colleague Ravil Bayramgalin taught me not to be scared of profiling: just “split and check”. > The idea is quite straightforward: split your code into two parts and test the performance of both parts. Then investigate the slower part in detail.
Everyone doing this should read the documentation on git bisect. It allows you to define a good version and a slow or bad version and uses binary search to find the commit that made the change that affects performance. Also very useful to find which commit introduced a bug.
There's a great book that's completely free 'Pro Git': http://git-scm.com/book/en/v2
It should be able to answer your questions from any range of expertise.
I want to give you the answer that this is a fairly basic decision, but as you go up the learning curve, these answers become more philosophical. So, my ultimate answer is that it will depend on you and the team. Whether your personal, topic branches are local-only or if they'll be shared? Are you sharing through a central repo or doing truly distributed?
I'm going to assume the answers are 'local' topic branches and 'yes' to central repo because that seems the most traditional setup for effective work environments. Okay...
You're in your local repo, you've made some changes that you want to commit. Your changes are currently 'unstaged'. Use 'add' to stage them:
git add some_file
When you've made all the changes that you want to do (to fix an issue, to add a new feature, etc.), then you need to do a commit. (Please avoid using -m 'short message', instead use the popup editor and write a good, detailed message:http://chris.beams.io/posts/git-commit/)
git commit
Commits are local in git, so nobody can see this change until you push it to a shared repo. The push syntax can be more complicated, but since I am assuming a central repo is used, then the command is simple:
git push
Which is equivalent to ('origin' is the default name for the original repo, and 'master' is the default name for the initial branch):
git push origin master
Either way, 'push' will try to share all the new commits you have created since you have done your last checkout from origin/master. Keyword being 'try', if you haven't done a pull in a while, then there will likely be merge conflicts. To avoid that, you should:
git pull
That'll to a merge commit which will allow to resolve the differences manually.
I've never understood why people insist on writing their own dot-file installation scripts when the venerable and powerful GNU Stow exists.
Edit: Also, I'd avoid having a full, generic .gitconfig in your repo. 1) There's security considerations, 2) The more systems you work on, the more you'll realize you need different settings for each boxen. I'd suggest splitting things out into git include files. See this.
> If the machine ourRepo has git set to /home/me/git then would the path would be /home/me/git/project?
No. git clone puts the repo in the directory you are currently in by default, you can specify a name for the folder else it uses set name. You can specify a path to store it if you don't want it in your current directory.
See: http://git-scm.com/docs/git-clone
> Would this make a repeated directory? like /home/user/repo/project/project
Git makes a folder based on what you set during clone or the name of the git repo in the current directory you are in. You can specify a custom path. See the git clone docs link above.
> Are these changes only committed to the local machine?
Yes, Git is distributed. Every repo has a local version of the codebase. It isn't until you push to a remote will another bare-repo have a duplicate.
> Will these intermediate comments end up on the main repository when pushed?
First off, there is no main repo. Most projects only have a single origin and seem like it is the main, but Git is decentralized. You can have multiple remotes for multiple reasons. We have remotes that are our Gitlab server, we also have deploy remotes. Yes all commits on that branch will be pushed to the remote. You can squash commits or interactively rebase if you want to merge them into a final bundle.
> How do they get updates of any files pushed to the repo after they checked out?
They git fetch --all to match their local origin to the remote. Then they can either pull (fetch + merge .. but they have already fetched so this is redundant) OR they can git merge origin/master as we have already done a fetch.
>I know git~~hub~~ can show me then once I've committed…
FTFY. GitHub doesn't do anything with a remote clone of a repository that Git can't do with a local one. Re: gitk.
You can check the version you have on each machine with bash --version, and you can check the changelog between the two version. Most of the time, you can expect a script running on one machine to run on the other. Unless you use a feature (or a bug) that was added (or fixed) between the two, of course.
You probably can run your scripts on windows too (assuming path, etc aren't an issue...), if you have git installed, it comes with a bash interpreter. For a full unix like environment under windows, check Cygwin.
I think most of the difficulty is trying to do tasks that are "optional" (ie, not needed for ideal usage of the program, but you will need at some time). For example, how do I stop git from making my scripts non-executable? Fortunately, there's absolutely no reason to remember (learn) these kinds of things. Just google when you need them. I still haven't memorized the syntax to restore a single file from an older commit, but I know where to find the command when I need it.
Pretty much all you need to memorize is:
- Cloning (getting a new repo from the internet)
- Checkout (switching branches)
- Pulling (getting changes from remote repo)
- Pushing (adding your changes to the remote repo)
- Diffing (viewing changes you've made, or changes between commits, branches, etc)
- Checking the status (to see which files are changed, etc)
- Adding (staging files to commit)
- Commiting (creating a revision with staged files)
- Branching (creating a new branch)
My advice when going from SVN to git is to FORGET EVERYTHING ABOUT SVN! If you try and apply existing knowledge about SVN to git, it will bite you in the ass. So don't assume that because you're competent with SVN that you know anything about git. This will stop misconceptions from hindering your learning.
As for a resource, the official tutorial is great. They also have a well written book for when you need more details.
Aww yuss, makin' a difference.
If you haven't already, I cannot recommend Scott Chacon's Pro Git highly enough. You probably don't need to know the lower-level stuff, but hey, that's like saying you don't need to know quantum mechanics - it'll probably come in handy one day.
Also, again if you haven't seen it already, Vincent Driessen's Gitflow workflow is one of the more heavily-recommended git workflows for non-trivial projects - understanding how the core ideas behind Gitflow (and other good workflows) mesh well with git will really help you confirm your understanding of the philosophies behind git, even if you don't use Gitflow yourself.
Good luck!
git saves locally, it was designed primarily for offline use. There's a .git folder in the repository's root that holds (technically, can generate) each version of each file. Pushing and pulling just adds to the .git folder- either your local one or the repo one. Every copy of the repo has every version ever committed.
It's not so hard to revert, or 'reset', to an older version.
Example:
Client asks for blue website
edit
git commit -m "Made site blue"Client asks for red website
edit
git commit -m "Made site red"Client wants blue again
git branch red git checkout master git reset --hard HEAD~1
First you committed a blue site, then you committed a red site. Then you created a branch called 'red' based on the current commit- a red site. Then you made sure you were on the master branch. Finally you reset the master branch to the commit that was blue.
Without connecting online you've successfully reverted, or 'reset', to an older version.
HEAD~1 means one version previous to current on this branch. You could also specify a the hash, tag, or branch of the version you want to reset to (c090e08021ef68360ab73ad99353d0686a164058, tagname, or branchname).
More reading:
http://git-scm.com/docs/git-reset
http://stackoverflow.com/questions/1616957/how-do-you-roll-back-reset-a-git-repository-to-a-particular-commit
Some things I'm using:
Beefy & Browserify are really handy for web development, no messing about reloading the browser and so forth.
Git for source control of course but also pushing things around, deploying, and so forth.
Mechanical Keyboard - It's one of those things that as soon as you do it, you wish you'd done it years ago. It's such a joy to type on, I can't recommend it enough. Check out /r/keyboards for information and advice.
Some things I'm looking for:
- A good inline documentation solution (like JavaDoc). I've tried several over the years and the projects either fade away or JavaScript isn't properly supported. The one that looked most promising was NaturalDocs, I liked their format, however that seems to have done nothing in so very long. Ideally I'd like something that runs under node.
GitHub is using Git http://de.wikipedia.org/wiki/Git
Git is really useful if you're coding, since it's possible to revert all changes you ever made. (also name them, and much much much more)
You can simply "Download ZIP" (to the right) or install Git to use it http://git-scm.com/ .
Once you've installed Git, you can e.g. use the command " git clone https://github.com/samdutton/simpl.git " to get that repistory (this link is provided close to the "Download ZIP" Button
If you're serious :
Git is a form of source control. Github, is a website where people can host their open source code and use git to manage it.
Source/Revision/Version control is basically what programmers use to manage different versions of a project. It also helps by allowing you to develop a feature on a different 'branch' of the project without affecting the 'stable/master branch' of it, and then 'merging' it in when the feature is stable. It's also really useful in finding and fixing bugs and reverting specific changes to a file that may have caused said bugs.
Aside from actual programming, I'd say version control is the single most important thing any software developer should know. It's used in pretty much every project, whether it be git, svn, or whatever.
One thing you can do with VCS commits is set up scripts that run at certain points in time, at pre-defined "hooks". You can write a pre-commit hook which will run on the current snapshot of the source before you even type a commit message, and a post-commit hook which will run after the whole commit. Git hooks here
Imagine a client-side pre-commit hook that ran a whole testing suite on the current state of your source, and failed the commit early if something failed. This can help reduce committed bugs, but it's also impractical if compiling and testing takes a long time. It might just slow down development. You can also create server-side hooks which reject commits that break certain tests.
There's all sorts of methods to this madness. You might want to read up on continuous integration, and look at this example, Jenkins, an open-source CI server. If you don't have a pretty good understanding of DVCS, you might want to read up more on git, one of the most popular DVCSs, and try it out before digging into hooks and CI.
I think this really shows what you learn in the workplace and not in college, bringing it back to the original question. There's so much automation and methodology to collaborating on source code, and until you start resolving merge conflicts and breaking unit tests, you won't know what you're getting into. It's fun, it really is, but there's so much to coding in the real world that isn't taught in college (but should be, in my opinion!).
It's like discovering copy/paste. It's like discovering keyboard shortcuts. It's like discovering how to save and load files.
It's so fundamental to programming, you'll kick yourself for all the time you wasted by not learning it sooner. Not to mention it's a core skill for any programming job, even more core than knowing any particular programming language.
If you're a Windows guy, I'd suggest getting started with Mercurial. If you're a Linux or Mac guy, I'd suggest getting started with Git. Nobody worth their salt is going to take you seriously as a programmer unless you have some knowledge of version control. I cannot stress enough how critical it is you learn it and use it.
git revert -m 1 $COMMIT
on the staging branch, where $COMMIT is the id of the merge commit for your f1 branch, should do it.
This will create a new commit that reverts the changes in that commit. Since the staging branch is shared, you cannot use rebase.
You may be using an old version of git where the default mode of git push is matching which pushes all branches that have matching names between local and remote.
Since git v2 (released in 2014) the default behavior is simple. The git docs here (find "push.default" setting) have a description of all the options, personally I use current as my default.
And there I go being serious on a ProgrammerHumor post lol. But maybe it'll help somebody
That is close to the truth. Technically, there is a <code>git request-pull</code> command, although it is not commonly used, because things like Github make it much easier to open a pull request from a web interface.
Yes it will work, git pull will automatically try to merge all changes, but that will fail if same line was changed for both versions, in that case you'll be given option to resolve this conflict.
I really suggest to learn about Git, it's very useful. Checkout "See also" from Arch's Git Wiki
About merge conflicts
> Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Right there in the sidebar. It is not a terminal emulator.
Here's the book on git. But essentially it boils down to:
git init- in the directory you want to be the repo. Starts tracking file changes, etc- Set up remotes
git add <filename/directory name>- stages changes made to that file/directory (recursively)git commit -m 'some message describing changes'- commits staged changesgit push origin master- pushes the commit to the remote server/github repo/whatever
Sounds like the major problem is your lack of understanding how Git works. I would sit down for a few days and read a book about it.
I have 2 kinds of projects on Github for my desktop configuration. One sets up my shell, the other one is full Xorg setup which includes the shell configuration as submodule. Both are to install with a script that check outs further things from Github (or updates them, if there is already a repo). Everything is managed with symlinks into the repository (that are created by the setup scripts), so when I edit a configuration the repositories get in dirty/uncommitted state. I don't need to copy anything manually, just commit and push it to Github. One disadvantage is that I need to update my setup scripts everytime I change a global feature (add a plugin, add a symlink etc).
Sound to me like you are misusing git. Try reading: http://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository
If I understand correctly, you make some changes. You are happy about those and you stage them. Then you make more changes, you are happy about those too, and you stage them.
The problem with the above is that you don't commit after the first set of changes. There is no reason not to make a commit. You can always squash all those small commits into one, if you want to. Once you are happy with what you've got, you can push all those commits to the remote repository. You don't have to push after each commit.
Anyway, your best friends in that workflow would be:
git add -uwhich would stage all modified files that are trackedgit commit -awhich would make a commit of all modified files (essentially, saves you from runninggit add -ubeforehand)
Do you need to learn how to use Github specifically, or do you need to learn how to use Git ?
Github is just a popular website, there are other like it (Bitbucket for example). It has its own functionnality, like pull request, but it's just a website.
Git is the version control system used by Github (but not only, it was created for the Linux kernel developpement, years before Github was around).
If you need to learn git, it's a very powerfull tool, but with great powers comes not so great usability. You can go there and there for example, to learn how to use it. (Don't worry, you don't need to fully understand it to start cooding. It was intended at first for a very big project, so you probably won't need most of its features.)
For github, it's fairly simple. I think the hardest thing to do is to find a project you want to contribute to, and to write some code for it. The process of writing and submitting the pull request is fairly easy.
If your in 3rd year in CS, maybe try to find someone cool in your class who can show you.
I believe what you are looking for is a "Software configuration management" (SCM) tool. "Labelling" is one of the features of these software wherein you can "label" different versions of a file and have access to all these file versions.
You can checkout the below link for more information on this. http://git-scm.com/book/en/v2/Git-Basics-Tagging
Numa nu incerca sa-l "prinzi din mers" sau sa treci asa rapid printr-un tutorial sau sa zici "las ca folosesc un GUI". Are un learning curve foarte abrupt la inceput, dar nu dureaza mult. Tre' sa bagi 1-2 dupa-amieze in citit primele capitole din documentatie (recomand http://git-scm.com/doc) si sa exersezi in timp ce citesti. Daca incerci s-o iei pe scurtatura ai toate sansele sa dai cu capu rau de tot. Dupa ce apuci sa prinzi conceptele e super ok.
tldr: n-ai 5 ani in pula mea, esti ditamai programatorul. Pune mana si citeste ca invatatura nu doare.
If you have ssh to the box and it has git installed then you have everything you need.
If you get tired of typing in your ssh password add yourself to authorized_keys:
Your computer:
- ssh-keygen
- cd .ssh
- scp id_rsa.pub :~/.ssh
Remote computer:
- cd
- mkdir .ssh
- chmod 700 .ssh
- cd .ssh
- cat id_rsa.pub >> authorized_keys
Then create repositories on the server, add them as remotes, and you're good to go.
git remote add livesite :/var/www/vhosts/yoursite.com/httpdocs git push livesite master
You can add a git only user to the server with edits to /etc/passwd so that only git commands can be run using shell tool called git-shell.
With my sites when I push edits they don't go immediately live. I have a separate bare repository on the server, after pushing I have to ssh and pull from the clone. The clone being the site's httpdocs folder.
To anyone that's interested I'd like to point out an alternative book on Git. I haven't read Version Control With Git so I'm not going to claim which one is better.
I read Pro Git by Scott Chacon which is freely available online. It's a great book that gets you up and running very quickly.
Since it doesn't sound like you're already using it, you might want to consider this an opportunity to begin using version control of some sort.
http://rogerdudler.github.com/git-guide/
Xcode has basic support for git.
Fellow web dev here. Using git as source controls adds pretty much no complexity and you can start using it properly in 5 minutes. From http://git-scm.com:
Creating and Commiting $ cd (project-directory) $ git init $ (add some files) $ git add . $ git commit -m 'Initial commit'
That's pretty much it. At any stage of your project you can pull a file as it was after any commit you've used. I use git mainly to work between my desktop/laptop but it also serves an awesome way to keep a backup of my work. You can use bitbucket.org for unlimited free private repos and keep everything you work on there. Setting that up is another few minutes and everything is well documented.
there are multiple reasons:
- binary packages aren't open and inspectable, there could be backdoors etc in there and they would be much harder to find. It's a trust thing.
- a lot of AUR packages are built directly from an upstream VCS repo, this way they are always automatically up to date.
- one has to always provide two binaries for the two supported architectures (+ ARM releases if supported)
- binary packages are often larger than the source
- if a library gets patched or updated the maintainer doesn't have to rebuild it
- (in general, whenever something changes, the maintainer doesn't have to recompile and distribute the package)
- as /u/whiteychs said, there are often configuration options and different versions to install (for example many tools like vim and irssi have optional scripting language bindings) that depend on your system and personal preference.
the github documentation focuses on the collaborative capabilities because that's what github is for. Github hosts git repos for open projects and provides other related services like source commenting, pull requests, wikis etc. You don't need the github docs, you want to learn git itself: http://git-scm.com/book/en/v2
btw git is designed specifically with source code in mind, it performs far worse when dealing with binaries (like compiled packages).
Git is a distributed version control system designed to make managing software development easier. You should use it to help keep track of changes you make to your software and to collaborate with other developers. You get it from http://git-scm.com.
>After the git add . how I can give different commit messages to each file ?
Don't do a "git add .". Only add the files to which a given commit message will apply. Commit them, then add the next set, etc.
If the default editor confuses you, change it: git-scm.com/book/en/v2/Customizing-Git-Git-Configuration.
They are different front-ends for viewing a set of commits. They're not interchangeable, but they do similar things. The manpages offer the best explanation:
http://git-scm.com/docs/git-show http://git-scm.com/docs/git-log
Regarding why these two commands are similar, Git initially emphasized a separation between its core command set (its plumbing) from its user-friendly commands (its porcelain). This division means that many user-facing commands will defer to the plumbing for their implementation. This explains why you find redundancies or overlaps in responsibility; higher-level commands have no qualms using the same low-level behavior. Nowadays, Git comes with a much more capable command-set which means you'll find similar behaving commands (e.g "git log" and "git show"). The extra options can be desirable, as they provide additional flexibility to the user; this is in contrast to low-level plumbing, where the redundancy would be more confusing and less desirable.
Git and github are different things. You can use git without github. There's nothing special about github - there are competitors like BitBucket and GitLab, and anyone can create a git server.
If you did want your own personal server, (chapter 4 of docs). However - I may be misunderstanding the question - but it sounds like you just want to use git for your own personal organisation? If you're not going to be using git in any collaborative way, you don't need a server. You can just commit and maintain your local repo, without ever actually pushing to a remote.
As for GUIs, again github is just one option. There are loads of alternatives. Just google or see here for some examples.
It's good and free.
Learn what these commands do:
> git init fooname
> git clone fooURL
> git add filename
> git status
> git log
> git commit
> git push
Then keep reading afterwards.
Why don't you create a personal project to learn instead? Contributing to OS is more for experienced devs. It's not meant as a learning experience for inexperienced ones.
As for how git works: http://git-scm.com/book/en/v2
Coming from a programming background; I really prefer Git. (Or some other versioning software; git mainly because you can do it offline and don't need to set up anything online)
No version appending to your file names, just setup your project folder structure (with a macro!), and create the initial files. The client just gets the zip of the current checkout of the repository.
Then commit upon changes, and if you truly want to know which version you had, tag the commit, so you can switch back to it later on with a click.
Once you get used to the whole system of git, everything becomes much easier and "saving" a file doesn't become a burden due to the heap of files you'll end up having which leads to you saving far more often.
Just use a graphical client (Smartgit or SourceTree) if you don't want to deal with the commandline (like me). http://git-scm.com/downloads/guis
First try to understand what git actually is. Once you understand what git actually is/does then you can simply follow the GitHub documentation.
git seems to be what most folks are using these days so you'd do well to learn it. The book should get you started - you probably only need the first chapter or two as the rest gets into crazy situations you probably won't be faced with (at least now.) I haven't used TFVC but if it's anything like earlier versions of MS source control, git will be much more pleasant once you get the hang of it. If you do decide to go with git, learn to use it from the command line. GUI tools are ok for merge conflicts, but really you should just do everything else from the CLI.
One of the most important things (imo) is missing: Git and its GUIs. I settled for GitX (Mac only) and occasionally use GitHub for Mac or just the command line.
Also useful is ColorSchemer Studio for color scheming and Base (Mac only) to manage SQLite databases.
*i'm still too dumb for markdown :(
My suggestion is: draw a picture. Don't laugh.
Put the objective of the story, the wanted end, in the very bottom of the page. Small blobs with description of important scenes in rough top-down order. Plot points, named appropriately, as arrows going between blobs.
If a scene needs a plot point to work out or even exist, the arrow points to it or passes into it.
If a scene (or several) gives origin to a plot point, start the arrows there.
Put the planned scenes somewhere in the rest of the page (must be a very big page!) and try to see how they connect with the previous ones and the story end. Use "?", "!", "?!", "wtf", "profit", etc, as needed.
Then, remove one plot point, and all scenes depending on it. Redraw everything, because it's a mess by now. Then scramble to edit the story.
Pro tip: If you write in plain text, or even in document formats like Word or LibreOffice, use a version control software to save versions of the story, and get back to them if needed. Better than deleting a 5-page scene, and two hours later discovering that you needed it, after all. I use git when writing and progamming:
Free, easy install, and with help and a book in the site.
If you are looking to ever work in a team, you will need to know git (or whatever vcs they use). It's not hard to jump into it and you'll be able to get by with just a few commands at first.
Once you get accustomed to it, you will wonder how you ever lived without it. Get an introduction to the concept of version control here: http://git-scm.com/video/what-is-version-control
As far as being a recent "invention", the whole industry is a recent invention and is constantly re-inventing itself every year. Git surfaced in 2005, written by Linus Torvalds for linux kernel code management. However, VCS as a concept has been around since the 70's.
If I understand your problem correctly, you want to keep your client's repo(s) in sync with yours but you need to use email because the client prefers that.
In that case, maybe it would be worth looking into using git bundle instead of patches. Then you are transferring copies of the actual commits rather than information necessary to create new commits.
Not sure if the client wants to do that, though.