We’ve been blessed with over 30 new students this year, of which about 10 want to program.
I think it’s safe to state we’ll be making heavy use of git branch/merge.
Does anyone have a succinct explanation of branch/merge suitable for consumption by brand-shiny-new programmers? I still have 3 sessions of classroom time, and I can spend one of them on this (with labs!)
I’m starting to roll my own based on the Pro-git explanation, but don’t want to re-invent the wheel, especially since someone else’s is likely to be rounder than mine…
At work I rolled out Git to 50 veteran engineers back in 2013/14. It took lots of teaching modules for various levels of understanding. I’ve taught a few more newbie-type engineers since then. It was far easier to teach Git to the new guys since they weren’t already mired in Dimensions or SVN type design workflows.
It will take 1-on-1 time - don’t underestimate that. The key for me seemed to be to find the 1-2 engineers who understood it early and then became enthusiastic about it. They were able to help me explain different situations from different perspectives based upon their experiences with it.
I’ve used git for many non professional things (some robotics, some game design) and I’ve found that the easiest way to get someone involved in git is to just hand them the app, hit commit, and see what happens. Once they see, they’re usually like “oh this is so cool”. Than after a while with basic commits and whatnot, you can teach them branching, pulling, etc. as you’d teach a subject in school.
This was basically our team during the 2015 season, though working with only 1 programmer and 1 mentor. I guess we’ll have to read up on Git for the 10 new programmers for 2016 :ahh:
Git can be hard to wrap your head around. I am used to using ClearCase at work for the past 10 years and when I jumped on a new project that used git, it was tough to keep up with it. Then I started mentoring FRC and the students are asking me questions about Git… and I don’t know the answers :o
It is a good course to start, but I am going to have to cruise through it at least one more time. Git is a bit of a leap from the things I have been using lately, DesignSync and ICManage. It helps if one knows the Unix command line and can probe around a bit.
Assuming no reference to a previous repository: Maven, Mercurial, SVN…
Here are some bullet points that could be polished up:
A git master (is actually itself a branch and often the first branch in a repository) contains your code release from an environment. It’s essentially the work product as it comes together. Keep in mind that in enterprise environments you release code for testing in the development environment. Then clone the code into a QA environment(s) for system integration and business acceptance testing. Then clone the code potentially into a non-functional testing environment where you test to see what happens if something goes wrong. Then clone the code into the production environment. Each environment has an owner and a separation of duty in a large tightly restricted enterprise. Though in some small environments the completion of master in your development environment goes straight to production accumulating risk.
…
To update a project for release you merge to master. Someone who is a release manager can check your merge. Merges can sometimes fail and if they do you want someone experienced to fix it.
…
When you checkout master you get a local copy and you push your working effort back to a branch on that remote server. You can update your branch as you like. Whatever you put in your branch doesn’t impact master until you make the merge request. You can switch branches without doing a commit to the remote git server doing a stash (do not confuse the Atlassian product previously called Stash with the operation).
…
A typical operation for a git user might look like this:
git add * (get all the changes to my local copy)
git commit -m ‘I fixed the stack overflow’ (commit this change and put a message on it)
git push (push it to the remote server)
…
A single git server can contain multiple repository.
…
Git has automation features like hooks. These programs or scripts can be activated by various events and perform tasks. For example a merge to master can cause an automatic build and deployment into your development environment. This can also be done with a CI/CD tool like Jenkins.
…
Git can be extended by adding custom commands.
…
Git can be wrapped by various web interfaces like: gitlab. These make administration easier.
…
Atlassian (JIRA/Confluence) makes a supported version of git in Stash now called BitBucket.
…
GitHub is git hosted as a service on the Internet. You can host git yourself as well.
…
Head in git is a pointer to generally the most recent commit. Assuming no one does something that trashes git history (and it can happen if someone goes in and tries to cover their tracks).
…
In git origin is usually the remote server.
…
Git supports tagging - but be aware that a git tag will apply to the entire repository which differs from similar behavior in other products. This feature can be used to mark versions of interest beyond head. Say you made version 1.1, 1.2 & 1.3. Say you did around 100 commits between those versions. You can tag the finals for each version so you can find them using the tag. This way if you need to roll back you have a place to quickly reference.
…
Git commit messages can not be easily altered after the fact. Tags have a similar behavior. If you want to have a scratch pad to put comments into your commits and change them later use git notes. Typically you keep the messages and tags brief and put long verbose comments into the notes because you can change them later. This can be leveraged for automation as well. Be aware the Internet based GitHub no longer supports git notes at least they stopped in the later part of 2014.
The place I interned last summer used ClearCase. Coming from Mercurial and Git, ClearCase is extremely different. Actually, ClearCase is different from everything else out there today. I totally understand where you’re coming from.
I was just looking at this today. I thought some of the examples in: https://www.atlassian.com/git/tutorials/comparing-workflows
was reasonable. There are other pages in this site as well, but this was page seemed like a good intro (looking at the examples and following the workflows).
