Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I've used tortoise SVN for a few years but now moving into using Git. Could anyone explain what the process is for doing the following in Git:

Get latest, Check in

I have managed to clone the repository successfully, made changes, committed then pushed the changes. Git says all is OK but I can't see the changes coming through on the remote server.

My set up is:

Remote server with Git repo on and Dev machine which connects to Git to take a local copy of the solution to work on.

Also, when I view the history on my local machine, all is good! It shows all the history, when I go to the server, the changes are not showing!

If I am not doing it correctly, let me know!

share|improve this question
    
Can you show what commands you're using to determine the server status? –  pcm Aug 30 '13 at 23:29
    
Also, did you create a bare or development repo on the remote? –  pcm Aug 30 '13 at 23:29
add comment

3 Answers

@Funky,
Since you can see history locally, I am assuming you are able to commit your changes properly to the local copy of your git repo. It is not clear what you are doing on the remote ('the server'): "...when I go to the server, the changes are not showing!". Depending on how 'the server' (remote) is configured, you may not see things the same way as you would on on your development machine.

If you are certain that your changes are indeed not present on the remote ('the server'), you may just be missing this (on your local dev machine):

git push origin master

A git status before and after the above command will give you useful information on any discrepancies bewteen your local and remote copy.

To double check, go to another machine (or another folder on the same dev machine) and do: git clone <git-url-of-your-server>. And verify if your changes are there.

share|improve this answer
add comment

To answer your question ... There really isn't a 'Check in Check out' process in Git. Those references are for Centralized VCS not Distributed.

With a Centralized VCS there is one absolute code base ... The source. With a Distributed VCS it's not so ...

Git has an abstraction layer called the index that separates the working directories code from the repository. In that respect you have to add your changes to the index and then commit them to the repository. But, that commit doesn't reflect a direct update to the working directory.

In order for you to physically 'see changes' on the remote side after a commit ... You need a hook to broadcast to the remote working directory to pull from the updated repo ...

Presumption here ... But I'm assuming you want to do something along the lines of a web site management workflow. Using Git to Manage a Website

Git is an extremely powerful and robust DVCS ... However, you need to fully understand how it works to effectively use it. With all due respect, I suggest you fully read the documentation. However, here's a highly reputable starting point :-) Git Magic

share|improve this answer
add comment

I'll show my workflow using github as server for my repositories:

If I've not nothing on my machine:
$ git clone git@github.com:<username>/<repository-name>.git

Now you have your local copy. If you already have a copy, do not need to clone again. Just pull:

$ git pull origin master

This command download from server to your machine all the updates.

Now you can work. Make commits. When you are ready. You can push your code into the server with this commands:

$ git add .
$ git commit -m 'some stuffs'
$ git add .
$ git commit -m 'some others stuff'
...
$ git add .
$ git commit -m 'some others stuff'
$ git push origin master

Command "git push origin master" put your code on server. If other users have pushed some commits!?!?!? Well: before push your code, you need to run "pull". This is the sequence I prefer:

1:

$ git pull origin master // now I can start to work

2:

$ git add .
$ git commit -m 'some stuffs'
$ git add .
$ git commit -m 'some others stuff'
...
$ git add .
$ git commit -m 'some others stuff'

3:

$ git pull origin master
$ git push origin master

If there are some conflicts after pull, just fix them, add, commit, and finally push.

share|improve this answer
    
You should use git pull --rebase to avoid cluttering the history with useless merges. –  psusi Jun 13 '12 at 18:30
    
I prefer $ git merge <branch-name> --no-ff. Thank you for feedback –  sensorario Jun 14 '12 at 7:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.