Tag Archives: git

getting started with gitlab

Posted on by
1

CodeRanch is talking about moving to Git for our source code. Some of the moderators expressed a preference for GitLab. I’ve used GitHub, but not GitLab so decided to try it out with one of my personal projects. Looking at it, GitLab has built in CI so I want to see if i can switch to that and get off Jenkins for my pet project.

Signing up for GitLab

You can register with a new account for GitLab or use your credentials for other services including Google, Twitter, GitHub and BitBucket. It feels weird to me to sign in for a version control system with the credentials for another version control system so I created a new account.

While signing up, it automatically imported my gravatar. I had an old picture on there so fixed that. I then added some basic information to my GitLab profile

I set up an SSH key to make it easy to commit from my home computer:

  1. Settings
  2. SSH Keys
  3. Paste in key

I also set up two factor:

  1. Settings
  2. Account
  3. The very first option is “Enable two factor authentication”
  4. It uses Google Authenticator which is my first choice of two factor. They also supply backup codes.

Migrating a repository from GitHub

GitLab has a page about migrating from GitHub. The most important pre-requisite is to make sure each committer to the GitHub project has an account on GitLab. Conveniently, I am the only person who has ever committed to this project!

I then migrated in:

  1. Create a personal access token on GitHub just for this migration
  2. Click “Create a project”
  3. Choose “Import a project” tab
  4. Enter personal access token for github and choose “List your repositories”. Note that this lists both your personal repositories and all of these for GitHub organizations you have access to
  5. Click “Import” on the row next to the repository to migrate. (There’s also an “Import all” on top. I’m not looking to migrate all my repositories though!). Nothing appeared to happen for a minute. I must have missed a status warning. But then the page refreshed and had a “done” checkbox.
  6. Delete the personal access token from GitHub. I don’t like to leave extra access laying around enabled

I confirmed the same number of commits (including the latest), branches and tags are all there.

Jenkins integration

I’ve been running this job on Jenkins each night to check for changes. Since this is a public repository, accessing it for polling is easy and worked on the first shot. While I’d like to switch to GitLab CI, I’m going with incremental progress. GitLab has a good page on interacting with Jenkins.

I temporarily made this a private project to re-test. I confirmed that I could commit and that Jenkins failed to pull. Then I tried to set up Jenkins to be able to interact with project.

When using my own account, I can set up a token with read access to all my projects, but not a specific one. I think I’d have to create an extra account on GitLab for Jenkins if I wanted it to have only access to specific projects. Since this is just an experiment, I’ll use my own token for now.

Failing with the GitLab plugin

  1. Installed the GitLab plugin on Jenkins
  2. In GitLab, went to Settings > Access Tokens
  3. Created a token with read_repository permissions
  4. In Jenkins, manage > Configure System
  5. Add a GitLab Connection. I like that it uses Jenkins Credentials for securing the token
  6. Click “Test Connection”
  7. Using https://gitlab.com/boyarsky gives Client error: HTTP 401 Unauthorized
  8. Using https://gitlab.com/ gives Client error: HTTP 403 Forbidden

I noticed that the Jenkins GitLab plugin is not well supported. The primary committer wrote that he doesn’t use GitLab daily anymore and this affects his time spent on this project.

At this point, I gave up and just set up polling. I created a credential with the username boyarsky and the password as my personal access token. (That I set up while attempting to get GitLab working.) This worked on the first shot.

Now time to start looking at GitLab Ci…

[2018 oracle code one] beyond git add/commit/push

Posted on by
Reply

Beyond git add/commit/push
Speaker: Jorge Vargas and Victor Orozco
@edivargas and @tuxtor

Full deck: http://www.jorgevargas.mx/wp-content/uploads/2018/10/Git-SCM-en-v5.pdf

For more blog posts, see The Oracle Code One table of contents

Review

  • add – puts in to staging area (from working directory)
  • commit – puts in local repo
  • push – puts in remote repo
  • reset hash – override working directory with local repo
  • fetch – get from remote repo to local repo
  • pull – fetch + merging into your local branch
  • clone – get from remote repo to working dir

Workflow

  • select a workflow – varies by project, but all team members should know what using
  • Common workflows
    • Centralized – all commits to master. Usually for new git users.
    • Feature branch – do feature in a branch and then merge in.
    • Gitflow – do changes in branch and merge into develop. Then merge development into master. Only commit to master for hotfixes or when develop ready for release
    • Forking – copy of repo and merge in
  • Recommendations
    • No one workflow to rule them all.
    • Code in master should be complete and functional at all times
    • Create short lived branches
    • Use meaningful names for branches

Advanced Git commands

  • stash – a quick save of your working directory

Demo

  • git init – to create repo
  • git status – showed file in staging area
  • git commit – add file
  • Edit .gitignore – to omit .class files
  • git log – see actual commit
  • git log –oneline –graph –all – list commits one line per commit so easier to read. Shows which branch the change is in
  • git checkout -b newBranch – create new branch and switch to it
  • git branches – list all branches
  • git checkout master – switch to master
  • git checkout -b branch2 – create a second branch off master
  • git merge newBranch – first merge smooth
  • git merge branch2 – created merge conflict. Fix manually
  • git branch -d newBranch – delete branch

My take: I had trouble understanding their accents at first, but then it got easier. The content itself was good. I was also a little distracted getting ready for my session next. I like that they did a live demo. I thought the content was going to be more advanced. The mention of stash was a good one. But then the demo was easy. To be fair, a bunch of people in the room didn’t raise their hands for using git. They got to the advanced part right when they ran out of time. I look forward to reading the rest of the deck at least.

 

 

DevNexus 2018 – Intermediate Git

Posted on by
Reply

Title: Intermmediate git
Speakers: Amanda Olsen

Deck with pictures

For more blog posts, see the DevNexus 2018 live blogging table of contents

Beginner git

  • add
  • commit
  • push
  • fetch – gets latest for other branches (I didn’t know this one)
  • checkout
  • pull

Concepts

  • current branch – the branch you are in when you run a command

Merge

  • git merge feature – merges the code from feature into current branch. All commits since branched in same commit in your branch
  • One cycle of merge conflicts (if merge conflicts)
  • If look at git log, see full chronological history looks as if all changes were made in one branch using original commit numbers.
  • Can see time of initial commit (from history looking like there).
  • Can see time of final commit (from the merge commit)

Rebase

  • git rebase feature – applies the commits one at a time but don’t have merge commits.
  • Potentially many cycles of merge conflicts
  • If look at git log, have new commit hashes for each commit
  • Don’t rebase a shared branch unless you coordinate the effort. If two or more people are developing in same branch, need to be really careful. Merge doesn’t have this problem. If you only have one person in a feature branch, it is a moot point. [at the robotics team, we have multiple people on the same branch; maybe this explains some of our challenges]
  • Rebasing rewrites history in that there are new commits. However, they are the same commits so it is more like a copy. Think of history as parent/child relationships instead. Since you have a new child/new commit, it isn’t really rewriting. Merge has a similar problem. It looks like commits were made in a branch when they were really made in a different branch and “moved” to target branch later.
  • Can see the time of final commit (from the commit)

Merge vs rebase

  • Merge
    • records that it was a merge commit
    • displays chronologically correct history if initial commits
    • Chronologically incorrect history of commits from perspective of master
    • Makes master more complicated
    • Difficult to roll back
    • Creates extra commits
  • Rebase
    • Simple master branch
    • Understanding master is easy
    • Rolling back is easy
    • Master doesn’t record when a branch is merged in
    • Golden rule – don’t rebase when multiple people working on a branch

Feature branch workflow

  • One branch per feature
  • Master is finalized work and intended to be bug free
  • Feature branches probably has bugs and that is fine
  • Very common workflow
  • Other workflows described

Rebasing

  • git rebase –continue – acknowledges that you merged one “group”
  • git rebase –abort – lets you start over

What to do when stuck

  • git reflog – portmanteau for “reference” and “log”
  • Remember that everything is saved if committed it. Local commits like a journal. (but then combine them before push!)
  • Commit any uncommitted changes
  • git reflog to find commit want to go back to
  • git reset –hard – move to that point in time
  • reflog goes back 90 days

Example with squashing commits

  • git clone
  • Create new feature branch
  • Start coding
  • Realize need the code from master
  • git fetch – pul remove branches/origin
  • git rebase -i HEAD-3 – reapplies the last three commits to the tip stepping through each commit. Combines them into one commit with a new commit comment.
  • git pull origin master –rebase – do a pull but rebase (instead of automatically merging). Faster to squash commits before rebase so less to go through when pull.
  • git push origin feature – pushes to the feature branch
  • Then can submit pull request so it gets merged into master

My take

Nice clear methodical explanation. I’m glad she mentioned what was “basic” git since I didn’t know about fetch. I like the recorded “non-live” demos. Great way to save time/reduce risk while still preserving the benefits of a demo.