I see on the git-tfs github page there is a way to map domain names to git names with the authors switch, however I'm looking to do the other way around, and up til now it does not seem to be working. I have a repository already pulled down, and I am trying to set up a new person working on our git repo (it was previously just me on the team), I've done some research and I can't seem to find an effective way of doing this.
I'm sure I am just being rather stupid and over looking something very simple.
Any assistance or direction would be greatly appreciated
There is no need of an author file for mapping in this "direction" because the one that push the changeset is authenticated by the TFS workspace created under the hood to push the changes.
But, indeed, you'd better share the exactly same author file (which is cached in the '.git' folder) for 2 reasons :
get exactly the same hash for each changeset fetched from TFS (and perhaps in the future share some commits between your local repositories)
if you push commits written by another colleague, the committer will be done with the identity of your colleague (if you active the good option in tfs) thanks to the author file (the mapping is used in the other way) and not with the identity of the one who push the commit.
Related
I did review several of the suggested articles to see if this answer has been given or documented already, but didn't find anything that seemed to answer it.
My boss wants me to create a new Project Folder in an existing Group Project folder ($/GroupProj1/MyGroup/New) and copy all the existing code from an old Group Project ($/MyGroup/CommandProc/Dev) "using TFS" so that the history of each file is preserved, e.g. "View History" of "$/GroupProj1/MyGroup/New/Solution1/NewMe.cs" is copied from "$/MyGroup/CommandProc/Old/Dev/Solution/Me.cs" but retains the history, or at least some link to it's history in the previous solution.
Is that possible?
If so, how? i.e. point me to the right docs, or whatever.
If this has been answered previously, then please forgive my duplication and point me in the right direction.
Thanks in advance!
It's not possible to move source code with history across team project boundaries.
There are some ways you can do it if you don't mind losing some degree of fidelity (such as original check-in dates and the original committer).
The process I've used is:
Use git-tfs to convert the source TFVC repository into a Git repository, containing all of the history
Point the Git repo created in step #1 to the new destination team project and use git-tfs to convert the changes from Git commits to TFVC check-ins, which will "play back" the entire history, one commit at a time.
As stated earlier, you will lose some degree of fidelity in this process. Specifically, the check-in dates for everything will be the current time, and I believe the committer will be the person running git-tfs.
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 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)
Intro
I've used SVN before, back when I was working as a solo programmer, just to keep an offsite record of what I was doing, so I kind of know about ideas like "repositories" and "commits" and the like, though not much more than that. "Branches", "merges" and "checking out" are, sadly, a mystery to me.
I want to start using Git because we've got a couple of guys who work away from the office and they have complained that they sometimes can't get through to some other version control systems because their IDE integration causes them to sulk and fall over when they get out of contact. Git's idea of "Every working directory is a repository" seems like it should go some way towards solving that.
Anyway, I've downloaded the "Git Extensions" to add The Shiny to the Windows context menus, etc. and I've found that I really have no concept of how I'm supposed to use this to control my versioning. Not finding anything obvious after a google search, I present the following theoretical scenario to Stack Overflow in the hopes that someone will tell me what to do, in small words:
Scenario
I have three projects. One project, ProjectReuse is used by the two other projects (ProjectA and ProjectB). Various people in the organisation will need to edit the code for each project, using Visual Studio 2010.
I have three folders on my desktop, labelled "ProjectReuse", "ProjectA" and "ProjectB". I've got the Git Extenstions window open. A cow, wearing a Santa Claus hat, is staring at me.
Questions
What do I do now to create the repositories in such a way that several people (including those pesky not-always-on-site guys) can access a repository when they need to, on-site or off, with or without a permanent connection to our servers?
When the first guy needs to edit a file, what does he need to do? Check out? Branch? I have to explain this to the other team members and I'm a bit wobbly on these concepts, myself. I've only used version control for my solo projects before.
Wheedling and excuses
The first "how do I set this up?" question is what I'm most interested in, but I figure if I'm going to ask for the idiot's guide, I might as well ask for it to be as useful as possible for the next idiot who stumbles onto this question. I'm not looking for particularly in-depth answers, here; I just haven't got any clear picture in my mind of how a multi-user version control system works. Once I've got that in mind I should be able to put the rest together by myself.
Ok, let's get the first thing about git straight. Git is distributed. Repeat this to yourself as many times as necessary: there is no central server, central repository or indeed anything central. Completely in contrast to SVN, you are not all accessing one repository (nothing central).
What you do is create a repository somewhere. Then everybody else clones (copies) it. Now everyone has their own copy of the repository and can do with it as they wish. Branch names don't even need to be consistent across repositories although many people do this as it helps.
So, how do you set it up? You init a repository then everyone who wants it clones it. In your case, I'd recommend each project have its own git repository rather than lumping all three together.
But but but how on earth am I supposed to manage a development team, I hear you say? Never fear. I said there was no central repository, but that doesn't stop you designating one of the repositories to be the release repository, and another to be the experimental or whatever.
What you need then is a workflow. Typically, what you do is create said release repository and then say: "everybody pull from the master on here". This represents your latest "stable" release. Now you tell everyone to branch from here and develop their new features. They do this. As these get done, you ask people to merge their changes back into their own master or wherever, then you, the release manager, pull from them (probably into a development branch but you could well do it into your release master because it is trivial to reverse commits). The next person then updates their master and does their merge. They resolve their own merge conflicts etc, and so on until you have all the features you want. You do your testing etc then the release repository really does pull all of that into its master.
In practice you might do many different things. For example, if you have a lot of people you're going to need quite a lot of communication going on, because if lots of people make incompatible changes to your shared project there's going to be a few merge commits. To avoid this, users can pull/merge from each other or use a local "shared" repository.
It does work.
As said by Ninefingers, just init a new repository and let others clone it. Keep in mind that when you want a public (or central) repository, create a shared repository and not a private repository. The easiest way is to create a personal repository first, and than clone it to a place (e.g. network share) where everyone has access to as a shared repository.
I created a few video tutorials for Git Extensions here:
http://code.google.com/p/gitextensions/
The video tutorials are a bit old and not very good since I do not have a mic or any video editing skills, but it should be enough to get you started.
Good luck!
I'm coming from a TortoiseSVN background and decided to give TortoiseHg a try. One thing I got really used to with TortoiseSVN was the SVN Repo-Explorer, which worked quite similarly to Windows Explorer. However, when I tried to use TortoiseHg's Repository Explorer, what I got was something else, it was more like TortoiseSVN's Show Log. It showed me what the recent commits were and what files were changed and even had nifty graphs. However, I'm still left wanting for TortoiseSVN's Repo-Explorer.
Does TortoiseHg have anything like this? How am I supposed to poke around the Repository if I can only view changed stuff?
I might be wrong as I have little experience with Hg myself, but I believe the reason TortoiseHg doesn't have a repository like its SVN counterpart is because Hg is a distributed VCS instead of a centralized VCS like SVN. So, the actual repository is your "checked out" copy. When you commit, you commit to your local repository, then you can push changes to other people or locations (such as google code, or your team mates). There are actually multiple different repositories for a project located in many places, instead of a single one, so there isn't really any meaning to "exploring the repository". The best you can do is check for incoming change-sets and view your local repository (using windows explorer).
This is mostly my reasoning based off a little experience with both. I might be wrong, but I hope this sounds reasonable.
This article might help clear it up: Distributed revision control. It took me some time to wrap my head around the idea of a distributed VCS too. In a nutshell, it's kinda like emailing your changes to your team mates. Everyone has their own individual repository, and each updates their own repository by getting change-sets from others.