Overview
Using GIT for core work like
- Creating a new local repo
- Adding files to it
- Committing your changes
- Looking at the history
Is reasonably straight forward and requires some reading and practice. The problem is, what do you do if you want to push your code to a server that other people can access. Imagine that you started a project local on your workstation and are now ready to share it with your team or other interested parties.
The goal of this document is to show how to take a local GIT repo and push it to a remote location. For this to work, you will need
- A GIT repo that is remote from your local home directory. That does not mean on a separate physical server but it needs to be a repo accessable through SSH or HTTP using something like GITOLITE.
- Your client side already has permissions to GIT on the target server.
- Permissions of RW+ to the new git repo. This allows you full admin to the repository
- A project that you are willing to push.
Fine Print
I am not a security expert nor am I a complete GIT expert. This HOWTO does its best to get you up and running with GIT so your team can get to work.
Assumptions
I am doing this using
- Ubuntu Linux 15.10
- GIT based on the Ubuntu distribution version
- GITWEB based on the Ubuntu distribution version
- PERL based on the Ubuntu distribution version
- GITOLITE based on a git clone from github.com
- You already have the Ubuntu distribution version of Apache2 installed and running.
For this document a project called mr_line_number will be added using uuklanger as an administrator.
My Ideal Setup
| Part | Description |
|---|---|
| Server Name | atomserver |
| Access Method | SSH |
| GITWEB | http://atomserver/gitweb/ |
| User Management | GITOLITE |
| REPO Base | /opt/data/git/repositories/ |
| GIT User | git |
| GIT User Home | /home/git/ |
Permission on the Server Side
For a push to any server, you will need two things.
- Permissions to access the server.
- Administrative permissions to create a new repo
The first is assumed where your public key has been added to the server and you can see projects like “testing.git”.
To add permissions
- Connect to the server as your GIT administrator
- Navigate to the gitolite-admin project which is located in ~/Admin/git/ for my configuration
- Add the new project mr_line_number and uuklanger with RW+ permissions. Also add gitweb with R permissions.
- git commit the changes
- git push the changes to the main server
$ cd $HOME/Admin/git/gitolite-admin/conf
$ vi gitolite.conf
$ cat gitolite.conf
repo gitolite-admin
RW+ = uuklanger
repo testing
RW+ = @all
repo mr_line_number
RW+ = uuklanger
R = gitweb
$ git commit -m “adding mr_line_number” gitolite.conf
$ git push
Once completed, mr_line_number will be a new project for git to manage through gitolite.
GITWEB Project List Configuration
It is likely that you will want your new project to be navigatable using GITWEB for quick searches/reviews. For this to work, the GITWEB projects.list will need to be configured. This will need to be done on your remote server.
$ sudo su - git
$ vi $HOME/projects.list
$ cat $HOME/projects.list
testing.git
mr_line_number.git
Once done you should have your new project visible in projects.list file for the “git” user.
Add the New Project to the Remote Server
Based on the status of your project mr_line_number, everything should be ready to go where
- The project is managed by GIT (locally for now)
- All has been added/staged in GIT
- All code has been committed to GIT
What remains is simply the push to the remote repository. The following is assumed.
- git is the SSH user with access to the GIT repositories
- atomserver is the target remote server
- mr_line_number.git is the name of the project on the remote server
- ~/work/mr_line_number (without the .git) is the name of the local workspace directory.
$ cd ~/work/mr_line_number
$ git remote add origin git@atomserver:mr_line_number.git
$ git remote -v
$ git push -u origin master
Since this was configured earlier, if you visit your gitweb site, you should now see mr_line_number in the list of GIT managed projects.
The parameter of origin is the remote name. You can name it something else as well. After the remote is added, you can view it in -v verbose mode.
In the future you may add other remotes for the project. In that case you will just change origin to something else like review if (for example) you have a team that reviews changes.
Where the -u tells git to use this server for upstream requests.
Getting New Project onto remote client
Once central to a team, it it likely that someone else may want to gain access to this project. For a user to do so, they will need to clone the project from GIT. In this case they want the project in their local system where they already have permissions to access GIT and this GIT project (via the gitolite.conf edited earlier but will need updated for this new user following the same procedure).
This user wants the project checked out into their work directory.
$ cd $HOME/work
$ git clone git@atomserver:mr_line_number.git
Once completed, you will see a new $HOME/work/mr_line_number/ with the expected contents.
Making and committing changes
If the user makes a change that are ready for the world they can be pushed to the central GIT
$ git push origin master
Note that the “-u” that tells git to use this server for upstream requests is missing. This is because the code was originally pulled from a central server so GIT already knows this. You can, however, change this if origin needs to become something else.
Conclusions
Using git it is possible to have a full source control system that you can use for managing end-to-end development cycles. When you are ready to share, you can push your changes to a central server for all to enjoy.
What is nice about a DVCS is that you can do a lot of local experimentation in branches without impacting other users.
This HOWTO will hopefully show how to push changes to a central location once the code is tablized and ready for the real world.
Created 20-November–2015 by uuklanger
Updated 23-December–2015 by uuklanger
No comments:
Post a Comment