Git Workflow To Enterprise Gitlab Instance

Description:

Similar to my post on how to connect Git to Github, this post is how to use Git to connect to an enterprise internal Gitlab instance. First, find out what branches exist in your company and what their workflow is. It is typically like:

Company Branches:
Production
Testing
Development

Typical Workflow:
development -> testing -> production

So you will ‘checkout’ development, make changes locally by ‘commiting’, then ‘pull/push’ often to development branch. When you reach a checkpoint, you will ‘merge’ development into testing/production assuming the code passes all checks.

To Resolve:

1. Initial Setup – Install ‘Git for Windows’ and ‘Github Deskop’.

2. Open ‘Git Bash for Windows’ and enter:

3. In Gitlab, add the ssh key to your account. Just copy the .pub file contents to your clipboard and paste it in.

4. In Gitlab, create a personal access token. Give it ‘sudo’ and ‘api’ for this to work. Copy it to your clipboard.

5. In Github Desktop, click ‘Clone repository’.
In the URL field, type https://yourGitLabInstance/name-of-repo.git
It will try to clone the repo and fail because of authentication. This is to be expected. In the credentials popup, enter your email address and your personal access token from step 4.

6. Check out the development branch
In Powershell:

In Github Desktop, just change the dropdown under ‘current branch’ to development.

7. Make a change to a file. For example, I just added a comment to the bottom of a file

8. Now, Stage all files since your last commit (which was never)
In Powershell:

In Github Desktop: The changed files show up automatically, just add a message and commit.

9. Adding your changes to Gitlab:
# Push them back to ‘company-repo’ under your branch
# The way it works is you first pull down changes, test to make sure your code works, and then push back up with your changes attached. Do this often!
In Powershell:

In Github Desktop:
Just press the ‘fetch origin’ and ‘push origin’ button every so often.

10. Merge with main branch – Production: NOTE: We will probably simplify this in the future, but for now follow this workflow

11. Switch back to your local working branch and keep making changes for the next ‘Push to production’ (Steps 6- 10) repeatedly.