I work mainly on a desktop Mac but also have a laptop Mac that I use when away from the office.
I want to access and work on my latest html, css, php and python files from either computer.
I thought Github was the way to do this but am having a problem understanding the "flow" and I've RTFM! I don't understand whether I should create a Repository on Github first, why when I try to "clone" something it doesn't magically end up on my local computer... where the nice big red button that says "sync" is...
... or whether I should just use the commandline ONLY...
So, if I start on my desktop and create new files, what are the correct steps using git or Github (?) to put those files where they can then be accessed from my laptop and then have the files on my laptop merged back into the ?Github repository so I can then access those files from my desktop.
Thank you all for your replies and answers! The git workflow, for my needs, is now clear.
The workflow presented by wadesworld is concise and was the overview I needed.
However, Michael Durrant's commandline steps filled in that workflow specifically with commandline directives - and I needed that also.
steelclaw and uDaY's answers and responses were important because I did not understand that it did not matter which repo I created first and, adding and committing locally were essential first steps in my workflow.
Specifically, steelclaw's response to one of my response questions provided the closure I needed, so I could learn more:
After initializing the repository, be sure to use 'add' and 'commit.' These will make the files an official version of the repository. After that, you need to use 'push' to upload it to the remote repository."
ilollar's resource, "Git for Ages 4 and Up" is also worthy of the click, especially for folks like me who are visual!
Thank you all so very much!!
Do you want to version control your files or just have access to the same files in both places?
It is a good idea to use version control as a developer, whether you're writing code or designing websites. But, to do so, you have to have a commitment to learning how version control systems work, since they all have some learning curve.
But, if you're not interested in that complexity and simply want to be sure you have access to the latest version of your files, then you're looking at a file syncing operation which can be much more simple.
So, which one do you want?
Edit: Based on the response, here's the model:
1) Create repository on work computer.
2) Create repository with same name on github.
3) Push to repository on github
4) At home, do a git clone to pull down the changes you pushed.
5) Now that the repository exists in both locations, you can simply do a git push before you leave work, and git pull when you get home, and vice-versa when going the other direction.
To answer the detail of your question: I'd go with Dropbox.
UbuntuOne is also good even for non Ubuntu users and of course Google drive is the (big) new player on the block.
They compare as follows:
Service Free*1 NextLevel*1 NextLevel($)*2 Features
Dropbox 2 50 $2.5O One Folder, best gui sync tools.
UbuntuOne 5 20 $4.00 Multiple directories anywhere
GDrive 5 25 $2.50 It's Google.
*1 GB
*2 Cost per month
To answer the title of your question:
If you wanted something that's more suited to programmers, I'd use git:
First, install gitx (linux readers, that's gitg) as that is by far the most popular gui for git:
For the "flow" I can also refer you to my write-up of various features at:
What are the core concepts of git, github, fork & branch. How does git compare to SVN?
Using gitx or gitg the specific flow is as follow:
1) Make some changes to files.
2) Use the tools "commit" tab to see what's changed ("unstaged"):
3) Add a file by dragging it from "unstaged" to "staged":
4) Give a commit message
5) Commit the file.
6) I then push it to the remote at the command line with $ git push remote or I use the gui by right clicking and select ing the 2nd master - see here:
.
If I'm sharing with others I'll often need to do git pull to get ands merge in others chnages) before being able to do a git push
The github part is doing init and push and clone but I'd say just read up on those tutorials more rather than an SO question. Basically though, I do:
Set up repository locally in git:
git init
git add .
git commit "Initial commit"
Set up github:
Create a github repository using github (https://help.github.com/articles/create-a-repo)and then push your local repository to it as in:
git push origin master.
If the repository already exists on github but not on your local pc, that's wheh you click the remote link and then in a terminal type git clone [paste here, e.g. ctrl-v]
If you're "starting" with github:
Make code changes
git pull - get latest version into your repository and merge in any changes
git add . Add all modified files
git commit -m "message"
git push # origin master is the default.
If, at the end of the day you decide to go with something simple like Dropbox you can use my referral link -http://db.tt/pZrz4t3k- to get a little more than the standard 2GB, Using this we both get an extra 0.5 GB, however which of all these routes to go is up to you and your needs. I use all these services (git, github, UbuntuOne, Dropbox and googleDrive, so I am not recommending one over the others -it depends on the needs).
I would recommend using DropBox or Google Drive. They will let you do EXACTLY what you are trying to achieve, they are very user friendly (and free [5 Gb I think]).
They automatically update (as long as you have an internet connection obviously)
Just make a folder, put some files in it, and you are away.
Since explaining how to use an entire VCS in one answer is an overwhelming task, I can instead point you in the direction of some very helpful resources to get you to understanding and using Git:
Pro Git - a free online book (written with Git!) with easy language on all things Git.
GitHub Help - GitHub's own help section walks you through setting up and using Git, and not just with their own apps. Very useful.
Get Started with Git - A good tutorial getting you up and running with Git.
Git For Ages 4 and Up - Fantastic video explaining the inner-workings of Git with Tinker Toys. Not best for an introduction into Git, but a great video to watch once you feel a bit more comfortable.
Git may feel complicated or strange at first, but if what you are looking for is a good version control system, it is excellent.
However, if all you're looking for is a cloud-like service to sync some files across multiple computers, like the others have mentioned, Dropbox would be the way to go.
I use Github as a "hub" of git, to share finished codes. (And Git for version control)
And Dropbox to sync files between different computers and mobile/tablet, to manage files.
http://db.tt/EuXOgGQ
They serve different purposes for me. Both are good!
Git is an advanced and rather difficult tool to use for version control. If you're feeling brave, you can try to install the command line tool, however I recommend using a graphical client, specifically SourceTree.
http://www.atlassian.com/software/sourcetree/overview
You'll need to clone your repository, or else initialize a new one. To connect to your repository, you'll need to know the URL, and possibly a username and password for your repository. You also need to provide a valid name for the repository.
To update files there are several steps: First, you need to add the changes to the directory. Source tree might do this automatically. Then you need to commit the changes. This is basically confirming changes and signing them with a comment. To upload them, you need to use push and select the correct remote repository. When you want to update your local repository, you'll need to use pull and again select the correct remote repository.
For your purposes, however, it seems like dropbox might be better, because it automatically updates and is very simple. If you don't need the advanced version control that git provides (e.g. branching, merging from many users), then it seems like it would be a better option for you.
https://www.dropbox.com/
Related
If I am version controlling my LaTeX docs and have a repo on bitbucket which I share with other conotributors, how do I share the png/jpg etc. files without having git tracking them?
Because every contributor should be able to compile it without LaTeX's draft check and visualize the complete paper with images, but it makes no sense to track such images with git (my .gitignore has a img/ line in it)
Check out the "Downloads" section of your Bitbucket repo. It is made for "adding any file that you would like to make available to your users, such as app binaries", which sounds pretty much like what you need. But you collaborators still have to download / unpack them manually.
Also, you can actually store binaries in Git repos. The problem is that they cannot be "delted" effectively due to Git internals and each binary file modification just duplicates all the bytes, even if you changed only one. So, if you don't change them frequently it's pretty ok. Bitbucket has a limitations on max repo size, so you'll get a warning when it is fool.
Another approach is to use Git Large File Storage which is especially created to handle binaries in Git repos. Unfortunately, it is not available on Bitbucket yet. If you can move your repo to Github consider this possibility.
First, a confession. In about 10 years of professional development, I've never used a source control system. There, that feels better. My historical setup (as recommended by management, ha!) has been to create dated folders on a server and copy-and-paste my data into it each evening.
I've known for a long time that a much better, manageable solution would be to use git or Mercurial to manage my source but I've never taken the time to learn any of these new tools because myold system has always worked well enough for my needs as the lone developer for every project I've ever worked on.
I have finally change this setup. I've installed Mercurial on my Mac, which after a bit of reading, I prefer over git. As a GUI front-end, I have installed SourceTree which appears to be easy to use and quite friendly. The problem I am having is that I can't find a very simple, straight-forward walkthrough for setting up a server repository that I use for pushing changes to each evening. I'm sure it's there, I just can't find it.
I've honestly tried to Google this, but there is something about the term "SourceTree". I can't find anything useful because half of the information I find is in regards to using git and it tends to involve pushing a project to a site like github.com, which is not pertinent in my case.
Additionally, I have skimmed the Mercurial documentation and I still may not be entirely clear about the full commit/update/push/pull/branch/merge concept. I just want to get something setup rather fast that will back-up and track the changes of my projects, without having to be a source control guru.
How do I setup a simple repository on a Windows network server, and push and pull changes each evening? My company want me to store my data in a personal folder, on a network share that is backed up to tape and is then stored off site.
I'm sure it has to be simple. I just want to be sure that I'm doing it correctly so that in the case that I need to access a back up, it is there and can be easily pulled... or branched.. or whatever.
Well, it depends on the kind of the server you are going to use.
Let's assume it's not a Windows server (just a guess, as you're a Mac user). Let's also assume that right now you only need it for yourself, not for a bunch of users.
Then the simplest way is to use SSH. Suppose the server is server, and you have an account rlh there. You'll need to have a public/private key pair for a seamless access (no need to enter the password on each pull/push). You'll need to install Mercurial on the server as well, obviously.
On the server, create a repo (in your home dir, for example):
rlh#mac$ ssh server
rlh#server$ mkdir myproject
rlh#server$ cd myproject
rlh#server$ hg init
On your machine, clone the repo:
rlh#mac$ hg clone ssh://rlh#server/myproject myproject
The default target will be set automatically, and you should be able to pull/push with no additional configuration.
Feel free to ask if you have a question regarding this.
When searching for hosting solutions, best not to include the term SourceTree in your query — SourceTree is just a front-end tool that is in principle unrelated to Mercurial hosting. That might explain the lack of useful information.
Here is an overview of ways to set up Mercurial servers:
https://www.mercurial-scm.org/wiki/PublishingRepositories
Personally I’m using plain hgweb and that has served me well.
Also I would recommend to consider using a hosting service such as BitBucket or Google Code. It requires much less effort to set up and maintain. Here is an overview of Mercurial hosting services:
https://www.mercurial-scm.org/wiki/MercurialHosting
Personally I’m also considering moving my self-hosted Mercurial repositories over to BitBucket, because of reduced maintenance overhead, and also it has functionality like bug tracker, wiki etc.
I'm studying art, but decided to take a course in programming. We were recently given a github URL, cloning it produced an empty folder(except .git). We were instructed to submit a solution to homework as pull requests on that project.
I don't want to mess up such a simple task, so I'd appreciate an advice on how to do the pull request. One of the things that bothers me are what parts of my folders and files do I need to include. I have folders like _ReSharper.Classes and packages (from NuGet), how do I handle those?
This is a good starting point for understanding Pull Requests:
http://help.github.com/send-pull-requests/
Basically on Github, hit the fork button:
This will create your own clone of the repository. Commit your code in the new repo (if you're completely clueless with git, check out a getting started guide like this).
When you're done, hit the Pull Request button:
Enter an explaination of your changes and submit.
As per Alex's answer, first you fork the github repo to create your own copy, though it is still on github.
Second you should clone that copy onto your own PC/laptop so that you can work on it.
Once you have the clone locally you should create yourself a branch to work in - this keeps the master branch available for reference.
Also use branches when trying new things so that you can keep the 'mistakes' separate from the good stuff before merging (often simply 'fast forwarding').
At suitable intervals push your repo back to github as a backup - check up on whether it is public (relative to any course restrictions)
I'm doing a single developer Visual Studio solution and reached a point where I'd like to incorporate Versioning Control. Several posts address this issue, but one problem I'm facing is a large merge. I have a production copy of the solution and a beta copy. They are NOT dramatically different, but they will require a number of interactions I suspect. I'm using TortoiseSVN and have imported the production version.
Yes, I know I should have used Version Control from the start, but that is hind sight. Would it be best practice to simply use the beta as a reference and work the interations from scratch. Or should I branch off and import the beta separately, then attempt to merge the change. Or is there another alternative I'm missing.
Thanks,
dgp
well, I have experienced SVN in the past ... and I must say, it's lovely cause it's really easy to understand the concept, but it's awful terrible when things pass from the plain commit.
I'm currently using GIT (to host small code on GitHub) and Mercurial (Hg) (I use Kiln in the company - was recommended by myself so they can start using - and in BitBucket for personal use)
I have used SVN for more than a hole year and every time I need something from "the past" or to merge something, it was a nightmare, but the server/client concept was really a break deal and extremely easy to get it... but I found my self, over and over to do merging by hand :(
When GIT started to be hot, I was afraid to move as, dang! SVN was a pain, why should be different in a DVCS?
This videos rocked my world, [ part 1 part 2 ], only then I understood DVCS vs VCS and it was with this that I moved COMPLETELY to DVCS and never go back... proudly!
For your problem, I would install git (or hg), and then create a repository on the folder you have your current source with:
git init will tell your folder, "Hey, I'm a GIT Repo"
git add . let's add all files and folders to be tracked by git
git commit -m "initial commit" let's save all the hard work :)
So, now you have a tracked code, you can simple create a branch and overwrite all your files. YES, worry not, you don't need to have copies of your code in a folder called branch ;) no more copies! all is in the GIT database
then, after creating the branch, changed the files, added all files to be tracked on that branch and committed, safely do a merge :)
ohh, and you don't need a server connection to do all this, all you need is a computer with GIT installed... no more connection dependencies! DVCS is cool or what?! :D
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Git GUI.. stage everything
My employer is finally looking into setting up some source control after much pleading by all of the developers. Unfortunately, none of our developers, inclusive of myself, have ever done much with source control. I've looked into SVN and thought that would be fine but another of the developers didn't like it. I've moved on to looking at GIT as an option. I've downloaded the GIT GUI from http://git-scm.com and started tinkering with it which brings me to my question/problem.
The web application we're trying to add to source control (GIT) is 7,386 files and 712 folders. When doing the initial commit, from what I understand, I've got to click on each file I want to commit to move it from the Unstaged Changes to Staged Changes pane. Well obviously I am hesitant to sit and click 7,386 times (once for each file to commit). Is there another faster way to do this?
I'm currently using this page as my reference to learn to use the GIT GUI http://nathanj.github.com/gitguide/tour.html. If anyone has a better tutorial/reference for using the GIT GUI I'd much appreciate linking me to it.
Thanks
To add every file (that is not ignored), use
cd /path/to/workspaceRoot
git add .
I don't use any gui, but I think this should be possible by adding a directory (the root directory in this case).
Remember to create a appropriate .gitignore file before, so no unwanted files get added. You can check, what is (un)staged with
git status
Also, there should be a context option (or something like that) in your gui, that provides status.
Extra: Additional git resource (quite good imo) http://progit.org/
From Git-GUI select all files in the "Unstaged changes" list and select "Commit->Stage to commit" in the menu.
If you're not afraid of the command line, try this tutorial instead. It's a detailed walkthrough of beginning git in 10 parts and ends with a Git reference card to help you go further. The free Pro Git book is also much applauded.