Git is a distributed version control system originally developed in 2005 by Linus Torvalds, the creator of the Linux operating system. Git commands are used to maintain a repository of git projects, where each project tracks changes to a set of files.
A fairly common activity for developers is to transfer a git project from one repository to another one. There are several ways to do this. However, the environments I typically work in have rather severe security constraints, so I’m not expecting one repository to have direct access to the other repository.
A Whirlwind Tour of Git
Git maintains a tree structure of file changes over time, which can be thought of as the history of changes to the files. The “trunk” of the tree is referred to as “master.” Branches represent a named fork, or set of changes, that have diverged from master. Branches can be merged into other branches. In fact, master is nothing more than a branch, so branches can be merged into master.
Over time, the usual goal of software development teams is to collect all of the tested and working changes to software files on the master branch. Other branches remain in the project, but are generally never used again. In a sense, the repository becomes littered with the detritus of hundreds or more discarded branches.
What to Move
When moving a git repository, it’s important to define what will be moved. There are three possibilities:
- Just the current source files
- The master branch and its history of changes
- All branches and the history of changes to all branches
History is important, because it allows one to see who made changes to the code, what they changed, and, if the developers were sufficiently disciplined, a description of why they made changes. History is vital for the changes to the master branch…but not so much for other branches. Either the changes were discarded, in which case we don’t really care about them, or they were merged into master when a feature was completed, in which case the changes are already present in master.
The bottom line is that option #1 is a non-starter, # 2 is my recommended approach, and #3 perpetuates a bloated project. It’s also possible to choose option #2, but add a defined set of other branches if necessary.
Transfer Process
In order to transfer a git project, we’ll export it from the source git repository and import it into the destination git repository.
STEP 1: Exporting a Git Project
1. Clone the git project into a temporary directory.
git clone
2. Go into the temporary directory.
cd
3. The clone action automatically brought in the master branch. If any other branches are needed, add them as follows:
git checkout
4. Fetch all of the tags from the git project.
git fetch –tags
Tags are basically alphanumeric labels that designate a certain “place” on the trunk, e.g. – “ver1_1” for version 1.1 of a software release.
5. Remove the link to the origin git project.
git remote rm origin
To verify that the origin setting has been removed:
git remote –v show
6. Go back up to the directory that contains your git project.
cd ..
7. Zip up the git project.
zip –r
By convention, provide a descriptive name for the zipfile, such as “zork_game_source_code.” There is no need to specify a “.zip” extension; that will be done automatically.
STEP 2: Importing a Git Project
1. Create a new git project in the destination git repository.
To accomplish this, go to the admin interface (for GitLab, GitHub, or other UIs) or command-line (for barebones git instances) for the destination repository. Create a new git project. Record the URL of the git project for later use (this will be designated as the “origin URL” in later steps). To avoid any potential conflicts, do not initialize the project with any files.
2. Upload the provided zipfile (containing a git project to be transitioned) to the designated Staging Server.
3. From the command-line of the Staging Server, unzip the provided zipfile.
unzip
4. Go to the newly created staging directory containing the content of the zipfile.
cd
5. Add a link to the new remote origin.
git remote add origin
6. Push the source files to the new remote origin.
git push origin –all
7. Push the tags to the new remote origin.
git push origin –tags
The git project has now been transferred to the new git repository. This includes the master branch, with its history of changes, and any related tags.