Here is a way to really learn Git with GitHub for enterprise use
- Narrative (captioning)
- git-flow software
- More on DevOps
This is for someone with a Git command-line client installed.
Watch the video below (a few times) to understand the sequence of commands in Git and GitHub.
Then actually type out the commands shown in the Narrative below, which provides additional alternatives not shown in the video.
Then, consider installing the multi-branch “Git-flow” software for enterprise teams.
Items are revealed gradually with narration in the video:
PROTIP: Print this picture and pin it on a wall for reference.
Let’s get hands-on typing each of the commands in the sequence presented in the video.
Here we have some stranger’s repository in GitHub which we have no rights to edit.
But if you fork it into your own GitHub account, you would then have rights to change it.
To work with repositories on your local machine, install a Git client. Its installation includes adding in your user home folder a dot git folder containing a config file. That file stores git global commands such as username and userid settings for attribution.
The “global” should be “–global”. This will be corrected in a future version of the video.
This tutorial is called “Git workflow” because it makes use of a Git client on your local machine.
Git commands are typed into a Terminal shell window on a Mac or a Run command window on Windows. Most IDEs incorporate commonly used Git client functionality into their software.
For example, in Eclipse, right-click on the project, then select Team for the Git menu:
Return to this picture after going through this course to see if you recognize what each GUI item does.
Clone in account folder
PROTIP: I recommend that you create an account folder to hold all your various repositories.
Be in that folder when you clone a repository from GitHub.
Git then creates that repo’s folder and within it a folder named dot git to hold objects that track changes to the repository.
During cloning, Git automatically extracts files from objects out to the repository’s folder, as if you typed a git checkout of the default branch.
Add parameter –recursive to pull in sub-modules (repositories stored within the repository).
Add parameter –depth=1 to only clone the latest version, to save disk space locally by not having previous version history on your machine.
Now we cd into the repository folder.
A git branch command shows us all the branches held in the repository.
The -avv parameter provides more detail. Dash a specifies remote tracking branches to appear as well.
PROTIP: Create an operating-system alias “gb” by adding in .bash_profile <pre>alias gb=’git branch -avv’</pre> then open up a new Terminal shell window to rerun the profile.
PROTIP: Git defaults to the master branch. But many organizations protect that name for production use, and instead create a “development” or “dev” branch for developers to work with.
The git checkout command controls what Git extracts out from the repository database to the repository’s folder.
- If you add a file after the git checkout command, Git will replace the file in the working folder with the version in the committed repository.
The dash b specifies creation of a new branch, such as “feature1”, to associate new changes.
- PROTIP: Atlassian defines its branches* with a type (feature, bugfix, hotfix, etc.), a slash, an issue number, then a short description.
The advantage of creating a branch is that parallel development can occur without risking the master branch.
Unlike Subversion, all files are available for change with a Git branch.
Now we can edit the file named README.md. The md designates markdown format. Such a file GitHub creates with this specific name to describe each repository.
We can use vim or another text editor (such as nano, atom, etc.) to change contents inside files. Batch files would echo text to the bottom of the file.
The git status command details the status of changes to the repo.
- This command is used so often that many create an operating system level alias such as “gs”.
You can change several files, but only the files you add to Git’s staging area will be pushed to GitHub.
The dot selects all files changed. The dash capital A parameter specifies that deleted files be processed. But many prefer to specifically add individual files to go into each particular commit, which works on all files added to staging.
Alternately, “git add -u” adds all the files modified (not new files created and untracked).
Some prefer using the single dash to avoid needing to press the Shift key to get the double quote.
The commit supplies a message describing changes, which applies to all files added.
- If you don’t specify the dash m, Git will display a file containing comments as a prompt. Any line beginning with the # comment character will be ignored and not be part of the comment.
The git log command provides a history of all commits. It has lots of options, so to avoid typing all the parameters desired, most people define an alias of the command in git’s config file.
If a colon appears at the bottom of the screen, press q to quit.
List a count of changes in each file in the commit (for example, abcdef1) with
git log --stat abcdef1
git reflog lists actions that have occurred on the local machine.
Before pushing to GitHub, some prefer to rebase to squash some commits so that only one commit message appears for several commits made.
Rebasing cleans up intermediate commits that is unwanted noise to the rest of the team. The extra commits complicates the history, and makes back-out of code more difficult.
Yes, this changes history, which is why we do it. But it’s only on your local version.
The git push command sends to a remote what has been committed for a specific branch. If you didn’t paste your public key into GitHub, you would get an error now.
When a commit is known good as the one to release, most organizations tag that specific commit with semantic versioning text.
git tag v1.3.4
Tags require an additional git push command to be pushed to GitHub.
git push –tags
Because branches are just markers within Git, once a feature branch is in GitHub, that branch can be deleted from the local repo and from GitHub (by specifying that colon in front of the branch name).
Unless you have been designated a committer in the upstream repository, you can’t push changes to it. But you can request their committers to pull changes from your forked repo. When a committer of that repo merges (or in other words, accepts) your PR, you’ll get an email from GitHub.
Next, let’s look at what happens if, over time, changes occur in the upstream repo. The git remote –verification command tells us that the origin remote was created, as usual, with the repo. To enable dowload by Git, we add the upstream remote.
To obtain changes locally, many would rather NOT issue a git pull upstream command, which blindly fetches and automatically merges changes. Differences in the same line within the same file, Git is forced into automatic conflict resolution mode.
So many prefer to take it one step at a time – first a <pre>git fetch upstream</pre>, then a <pre>git checkout master</pre>.
gitk for diff
Now we can use a utility such as gitk to see what changes came in.
Click the commit listed at the top, which is the most recent commit.
Alternately, there is also utilities vimdiff, meld, difftool, etc.
To see the difference between what is in last commit vs. what’s in the working folder:
- To see the difference between what is in last commit vs. what’s added in the index cache:
git difftool --cached
- You can make a default command such as this to explicitly specify some file to compare:
git diff HEAD HEAD^ -- file1
If they don’t affect you, do a git merge.
Notice the slash separator. Use a cat or less command to verify file contents.
git push origin master
Lastly, we git push to update origin master on our forked repository.
There are variations to these commands, but this is the typical workflow.
Vincent’s popular blog identified different types of updates at:
- Hotfix from master and back to master
These branches are used more in corporate rather than open source software.
Atlassian presents their take on the different branches in this video:
Instead of native git commands the “git-flow” command is issued with a branch and whether you want to start (checkout) or finish:
- git-flow hotfix finish branchx
- git-flow bugfix finish branchx
- git-flow release finish branchx
- git-flow feature finish branchx
- git-flow support finish branchx
Install the software:
Hubflow fork software
Datasift people created an upgrade to GitFlow to work with GitHub, which they call HubFlow
git clone https://github.com/datasift/gitflow cd gitflow sudo ./install.sh sudo git hf upgrade
The flow of hf git commands are explained at:
More on DevOps
This is one of a series on DevOps:
- Choices for DevOps Technologies
- Java DevOps Workflow
- AWS DevOps (CodeCommit, CodePipeline, CodeDeploy)
- Digital Ocean
- Cloud regions
- AWS Virtual Private Cloud
- Git and GitHub vs File Archival
- Git Commands and Statuses
- Data Security GitHub
- Git Commit, Tag, Push
- Git Utilities
- Jenkins Server Setup
- Jenkins Plug-ins
- Jenkins Freestyle jobs
- Dockerize apps
- Docker Setup
- Powershell Ecosystem
- Powershell on MacOS
- API Management Microsoft
- Scenarios for load