CODEWITHSUNDEEP
gitsvn
pg.
pg.

Reputation: 2531

setting up git for a simple use

I have used SVN for years and finally am going to switch to git. I don't understand how to do simple changes and the documentation is a bit confusing to me.

I have set up a repository in a folder called dev/ and I want to have another folder called live/ where I can update any commits I've made.

In SVN I would have done like:

svn commit dev/index.php -m "changing something"
svn up live/index.php

In git I have set up dev/, now how to I make live/? is it a clone? pull? What's the simplest way to do this?

Upvotes: 2

Views: 35

Answers (2)

VonC
VonC

Reputation: 1329292

You can clone dev:

cd /path/to/parent/of/dev
git clone dev live

Both dev and live represent the same Git repo on the same branch (by default master).

Since dev is purely a local repo, once you commit in dev, you need to go to live and do a git pull.

Another approach would be to consider live as an upstream repo of dev:

git init live
git clone live dev
cd dev
# work
git add . && git commit -m "message"
git push -u origin master

Then you would be able to push a commit from dev to live directly.

Upvotes: 1

Shannph Wong
Shannph Wong

Reputation: 141

There are a bunch of tutorials that you can look up, but as someone who had worked with SVN for many years as well, I know it can be a little confusing.

There are a couple of key concepts that you've got to wrap your head around.

  1. There is a workspace which is basically where you are working with your files. This is where you're making all of your changes on your local filesystem. When you like what you've done, it's time to get to the next step.
  2. One of the biggest differences is that there is a LOCAL REPO that sits on your machine. The next step is to actually "add" your changes to the LOCAL REPO. This is done with the "git add" command. NOTE: You do need to call "add" for every file you've changed - even if it's an existing file. (Unlike SVN where you just 'add' for new files.) Git considers this as adding the file to "staging" (your local repo).
  3. When you like what you've done, you can do a "git commit" which actually marks all the changes that you've made as history in your local repo. The whole idea is that 'add' just indicates to git to watch for the changes, while commit says you're finished your changes for those files.
  4. Finally, when you're ready to actually sync your changes to the remote server repo, then you use the "git push" to actually commit it to the remote server repo.

So in your case, you'll want to go through the 3 steps above. Create your directory first. Then do the "git add" to your local repo. At this point you can start using it to add more files in that folder in your workspace. Do more "git add" for the new files you've created. When you're satisfied, do your "git commit" to commit to the local repo. Then you can push to the server repo with "git push".

It does take a little while to wrap your head around this, like I said - but it starts to feel more natural when you get into it. The whole local repo thing is really nice to be able to work offline. It also feels like a lot more commands - but they all have logical reasons. No more of the SVN commit and then "oops I forgot to add this one too" second commits - all because you can handle those things with the "git add" and double check.

Happy trails!

Upvotes: 3

Related Questions