|
Git /
DanielsTutorialSo you clone a repo onto a local machine, and make some changes: git clone user@anchor:repo cd repo vim somefile git commit -am "edited somefile" If you must push to the server repo (e.g. because your client repo is behind some NAT firewall, like your home wireless) then the solution is to push from your client to a new branch on the server (not the currently checked-out branch): git push origin master:refs/heads/cloned # <-- invent a name, e.g. 'cloned' Now you can login to the server, go to the repository, and merge the new branch with the currently checked out branch: ssh user@anchor cd repo git merge cloned # <-- same name here Once you've created the separate branch (e.g. 'cloned') you can keep using the same one for future push requests. Branches are very powerful (and can be also quite confusing)! This is just one solution; there are others on that stackoverflow page. -D. On Thu, 2 Apr 2015, Daniel Morrison wrote: > Hi, > > SETUP of git > ------------ > > In a directory where you have files you want to keep under version control, > type 'git init': > > daniel@anchor:~$ mkdir all_my_scripts > daniel@anchor:~$ cd all_my_scripts/ > daniel@anchor:~$ touch script.sh > daniel@anchor:~/all_my_scripts$ git init > Initialized empty Git repository in /remote/home/daniel/all_my_scripts/.git/ > daniel@anchor:~/all_my_scripts$ > > A new repository is always empty (even if there are existing files in the > directory). You can type 'git status' to see what the current status is. > Files that exist, but have not been added to the repository are listed: > > daniel@anchor:~/all_my_scripts$ git status > # On branch master > # # Initial commit > # # Untracked files: > # (use "git add <file>..." to include in what will be committed) > # # script.sh > nothing added to commit but untracked files present (use "git add" to track) > daniel@anchor:~/all_my_scripts$ > > So in order to start tracking 'script.sh' in the repository, it needs to > be added, and then the change needs to be committed. > > I type 'git add script.sh'. Now script.sh is listed as a 'new file'. This > can be repeated in order to collect multiple files to be all added to the > repository at once (with 'git commit'). > > Then I type 'git commit' to save the new repository configuration > (essentially, to "publish" the changes made, so they can be cloned to a > new location). It automatically opens an editor for me to type a > descriptive message about this commit (normally only one line). > > To avoid launching an editor, you can include the commit message on the > command line with '-m': > > daniel@anchor:~/all_my_scripts$ git commit -m "first draft of script.sh" > [master (root-commit) ba84ec3] first draft of script.sh > 1 file changed, 0 insertions(+), 0 deletions(-) > create mode 100644 script.sh > > ------ Aside: your identity ------ > At this stage, the first time, there is a warning that "Your name and > email address were configured automatically", and a note that you can > update your preferred username, email, and "identity used for this commit" > by typing: > > git config --global user.name "Your Name" > git config --global user.email you@example.com > git commit --amend --reset-author > > If you're reading ahead, you can avoid admending the first commit by > setting your user name and email before making the first commit. Also, you > can edit this information directly in ~/.gitconfig, for example, mine is: > > daniel@anchor:~$ cat ~/.gitconfig > [user] > name = Daniel Morrison > email = Daniel.Morrison@phys.ocean.dal.ca > [core] > autocrlf = input > editor = vim > daniel@anchor:~$ ------ End aside: your identity ------ > > DAY-TO-DAY usage > ---------------- > > The workflow now generally consists of editing the files in the repository > until satisfied with the current state, then all changes need to be added > in order to 'stage them for the commit'. Any new files are untracked by > default, and still need to be tracked by typing 'git add newfile'. > Existing files that are already tracked can have their changes added > automatically with the '-a' (all) option to git commit. So, for instance: > > $ vim script.sh ## edit existing file > $ vim 2nd_script.sh ## create new file > $ git add 2nd_script.sh ## start tracking new file > $ git status ## check current status > $ git commit -am "added function to support XYZ" > ## commit changes on all tracked files > ## with message supplied > > Typing 'git status' regularly helps you to figure out what's going on at > any moment. > > If there are files that you do not want to add to the repository, but > constantly appear in 'git status' as untracked, you can ignore them by > adding them to the .gitignore file. > > 'git log' shows you a log of commits (including your helpful & > descriptive commit log messages and each commit has a unique hash (e.g. > ba84ec38518e05f4ef2da1a4faa08832c9054a8a). You can see your code changes > with respect to an older revision by using 'git diff' and specifying the > hash of the commit against which you want to compare. The hash can be > shortened to the minimum unique length (usually 5-6 characters is enough): > > daniel@anchor:~/all_my_scripts$ git diff ba84e script.sh > ... > > So this shows me the changes in 'script.sh' between the time it was > committed as identified by the hash 'ba84e....' and now. > > > CLONING and remote update > ------------------------- > > With git, there is not supposed to be a 'master' repository. Every > repository has all the information; which one is 'primary' is decided > purely by your work habits, and how the repositories were setup. However > in practice, there are problems trying to treat them all equally. > > A git repository is entirely contained within the .git directory. All the > git operations work on files in this directory. For you to work on files > normally, a "view" of your current working files is created, called a > "checked-out branch". The currently checked-out branch (by default named > 'master') consists of the files that you see when you type 'ls'. > > On any other system that has git, ssh, and ssh access to your 'primary' > repository, you can clone your repository like this: > > $ git clone daniel@anchor.phys.ocean.dal.ca:all_my_scripts > Cloning into 'all_my_scripts'... > daniel@anchor.phys.ocean.dal.ca's password: > remote: Counting objects: 8, done. > remote: Compressing objects: 100% (4/4), done. > remote: Total 8 (delta 0), reused 0 (delta 0) > Receiving objects: 100% (8/8), 719 bytes | 0 bytes/s, done. > Checking connectivity... done > $ ls -l all_my_scripts/ > total 4 > -rw-r--r-- 1 daniel daniel 0 Apr 2 16:42 2nd_script.sh > -rw-r--r-- 1 daniel daniel 10 Apr 2 16:42 script.sh > $ > > In this example, I have cloned the contents of the master branch of the > remote repository (on anchor). > > I can continue to make changes on anchor, and then type 'git pull' in the > cloned location in order to synchronize the copy. > > However, if you make changes to the cloned copy, and then type 'git push', > it gives an error, because you are asking it to upload changes to the > master branch of git repository on the server (in the .git directory), but > at the same time, the master branch is checked-out on the server (the > files). If this doesn't make sense, you can try to read a different > perspective of the problem here: > http://htmlpreview.github.io/?https://github.com/sitaramc/sitaramc.github.com/blob/dce410b2a2804723676db9cabd7bb506b6d9ba05/concepts/bare.html > > To solve this problem, you need to start using branches (so you can push > to a branch which is not currently checked-out on the server), or use 'git > pull' in every case (pull both ways, don't use push), or you can setup a > 'bare' repository, to be your master repository, and never be edited > directly. This is how github works, for instance. > > This has already gone a bit long, so I'm going to stop here, but there's > lots of discussion about the 'git push' problem here: > > http://stackoverflow.com/questions/2816369/git-push-error-remote-rejected-master-master-branch-is-currently-checked > > Let me know if you run into a specific problem with this... |