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)
Related
First of all, I am not sure if StackOverflow is the place to ask this (I already considered Programmers StackExchange, but that also seemed a bit off). If this is not the right place, please help me move the question or suggest where I can ask it instead.
If you're using TFS, is there an effective way to do reviews like GitHub offers? In GitHub, you typically submit a pull request. This pull request then lets you see all the changes made in that whole pull request, making it easy for you to review (because you can just keep scrolling down).
Can the same be done in Visual Studio with TFS, or do I really have to see the changes for every file that has been changed manually? It just seems crazy.
I'm afraid there isn't a single overview. You do have the code request feature but that still shows a list of files.
Instead of using TFVC with Code Reviews, you can also use Git as the version control system. You can then use regular pull requests in the same way you would use GitHub.
I am new to Git. I wrongly uploaded my code into GitHub repository with push command using Xcode source control. Then I asked a question that how can I delete the content of the master, because I thought that deleting files is enough to have a fresh start. (NB: I cannot delete the repository and create a new one) so I deleted every single file in repository with push command and the repository is empty now. When I try to pull my local working copy this time, my local working copy got deleted.
Does anyone know how can I pull my code?
There are two ways to go about fixing this problem.
Rewrite your history and push the rewrite to master (not recommended, because it will screw up everyone else's history as well, but has the benefit if making it appear that you never made a mistake)
Make a new commit reverting your changes and push this new commit. This keeps your old code in the repository but removes it from subsequent versions. It also has the added benefit of not screwing up everyone else's history.
To accomplish #1, simply run git log and find the commit ID number, then run git reset NUMBER to revert your tree to the working state. Then push your changes with git push RemoteName BranchName --force
As I mentioned, I strongly recommend against doing that unless you have some major privacy concerns over your mistake. A much better way to handle the problem is to run git revert CommitID to create a new commit that "undoes" your previous mistake. Check out this Atlassian blurb for a bit on how to do that.
I will start by saying this is probably a dumb question so apologies if I am staring at the answer but cannot see.
I have used VCS in the past primarily as a method of allowing me to revert my code if something goes wrong. I have always had a single lime of development. However I get into the usual trouble when releasing and starting the next version - dealing with bugs. So this time I decided to use branching (forking or whatever is the best name). I am a lone developer so I am the only one working with the repositiory. My scenerio is simple. I want to create a branch when I release so that I have a line for the released code and a line for the beta. I can then work happily on the beta. Now a bug comes in and I need to get back to the last commit for the release.
My question is what is the best way to get back that code in the IDE to work on it.
I have read that in Mercurial a simple way is to clone the repository including the working directory. This would give me two copies of the code base and I guess I can choose which one to load into the IDE. I would then use Push or pull to get the bug fixes from the release copy into the beta copy (I think).
I assume there must be another way however without cloning. How would I do that? I can guess at reverting to the last commit of the release code. Then I assume that loading the solution into the IDE would give me that. I am not sure where I would go from there when the code is done.
For the record I looked at a number of different VCS - I have used SVN in the past but wanted to go to a DVCS. I looked at Git, Bazaar, Mercurial and Veracity (and used Code-Coop in the past). You may think another tool would suit my needs better. Having tried the others however I found I could understand the way Mercurial works and the GUI tools such as TortoiseHg with the WorkBench and HgSccPackage (http://visualstudiogallery.msdn.microsoft.com/9bc074fa-9e1f-4ce2-a75d-b90e65f7475a) appeal
There are a lot of good documents and links here Introduction to Mercurial and I have read about different ways to branch that include using bookmarks and so on but they seem primarily targeted at multi member teams - which make sense of course
Many thanks in advance
You are mixing concepts a little, i guess you have SVN background ?
Just to answer you question, to 'get back the code in IDE' you will need to 'update' to a previous version. But this is considering you already have cloned the repository. Is your question about how to clone.. ? As you ask, there is no other way without cloning first. Cloning is the first step towards having a HG repository local. After clone, you can commit and push changes or pull and update.
To expand the answer even further and given that you are going to use Mercurial, here is what you should do:
read this : http://hginit.com/ - great HG (tutorial) by Joel Spolsky him self ! An introduction into HG and the concepts. You will need to understand this very good, since right now you are doing a lot of guessing, assuming and thinking :) HG/Git is different from SVN and in the begging the concepts might be hard to understand and to get used to.
for your project and regarding your question, have a branch called 'dev' or 'trunk' or 'version X' etc where you will commit all new changes.
have a branch called 'live' etc that will represent the current 'live' version. This way, whenever you need to revert back in time to the live version and to do a quick fix on it, you will 'update' to the tip of that 'live' branch, discarding all local changes (after you have committed to trunk! of course).
when putting a version to live, you will need to (assuming all changes are committed !) : update to the live branch then MERGE the version X into local (local being live ). This will include your versionX branch into live - it's what you need at this point. Then, either update back to version X branch or create a new branch - version X+1. This will take care of the versions and keeping the branches separate.
since you are using VS - install http://visualhg.codeplex.com/. HG source control integrated into VS.
I assume there must be another way however without cloning
Yes. You can use (named) branches inside single repo (I prefer HgSccPackage in VS), update to revisionbranch head, change, commit, merge
BTW, branching with bookmarks/clones/branches work the same (good) way for any size of team - it's a matter of taste
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/
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