Implementando CI com GitLab
Ainda que os tópicos da prova LPI DevOps não cubram apenas o Git para a integração contínua (ele é usado especialmente em Source Code Management), é muito importante conhecer bem os conceitos de integração e entrega contínua cobertos nessa palestra. Eles estão nesse tópico:
701.4 Continuous Integration and Continuous Delivery
The syntax for using git checkout to update the working tree with files from a tree-ish is as follows: git checkout [-p|--patch] [<tree-ish>] [--] <pathspec>… Therefore, to update the working tree with files or directories from another branch, you can use the branch name pointer in the git checkout command. git checkout <branch_name> -- <paths> As an example, this is how you could update your gh-pages branch on GitHub (used to generate a static site for your project) to include the latest changes made to a file that is on the master branch. # On branch master git checkout gh-pages git checkout master -- myplugin.js git commit -m "Update myplugin.js from master"
Windows Video Tutorial Download the Git for Windows installer. Run the installer and follow the steps bellow: Click on "Next". Click on "Next". Keep "Use Git from the Windows Command Prompt" selected and click on "Next". If you forgot to do this programs that you need for the workshop will not work properly. If this happens rerun the installer and select the appropriate option. Click on "Next". Keep "Checkout Windows-style, commit Unix-style line endings" selected and click on "Next". Keep "Use Windows' default console window" selected and click on "Next". Click on "Install". Click on "Finish". If your "HOME" environment variable is not set (or you don't know what this is): Open command prompt (Open Start Menu then type cmd and press [Enter]) Type the following line into the command prompt window exactly as shown: setx HOME "%USERPROFILE%" Press [Enter], you should see SUCCESS: Specified value was saved. Quit command prompt by typing exit then pressing [Enter] This will provide you with both Git and Bash in the Git Bash program.
Instruções de instalção do git para windows
Turn a GitHub repo into a collection of interactive notebooks
如何将开发的分支代码，merge到主干上？
$ git checkout -b dev
$ echo 'Readme' > ./readme.txt
$ git add readme.text
$ git commit -m "dev branch test"
$ git checkout master
$ git merge dev
$ git branch -d dev
$ git branch
git checkout -b dev
创建新的开发分支进行开发，与下面一组命令相同
$ git branch dev $ git checkout dev
$ git branch dev $ git checkout dev Switched to branch 'dev'
$$git checkout$$
命令加上 \(-b\) 参数表示创建并切换
该命令与 \(git checkout -b dev\) 相同
log --patch
same as git show
We could also use git show which shows us what changes we made at an older commit as well as the commit message, rather than the differences between a commit and our working directory that we see by using git diff.
show as in "show me what I did"diff as in "difference between working directory and ..."you’ll need to know up front that you want your commit applied into multiple places, so that you can place it on its own branch
More specifically, you'll need to know up front all the places you want your patch commit applied into so that you can determine where to start the patch branch from.
if you can anticipate where a commit may/will be need to applied
This is an important assumption.
The way I understand it, cherry picking is intended to be used in case of unanticipated migration of code.
its own branch
The patch branch should start at a common ancestor of all the target branches. Since the broken code is in all the target branches, it must be in at least one of their common ancestors.
If we don't start from a common ancestor and merge the patch into all the target branches, at least one of the target branches will get some extra change along with the patch.
it's cleaner to use rebase to bring your outdated feature branch up to speed with develop, rather than merging develop into your feature branch.
who collected / edited / published
git log & blame
$ git log -p [file]
显示指定文件相关的每一次diff
显示效果如下，但会显示高亮：
commit 32e0c4f6bbb91617126b1cf2ab8c403ce7691ffe
Author: lishuailong <lishuailong@baidu.com>
Date: Tue Jul 11 15:14:59 2017 +0800
delete by loc
diff --git a/bin/server_control b/bin/server_control
index 6d81daa..4cf5106 100755
--- a/bin/server_control
+++ b/bin/server_control
@@ -48,7 +48,7 @@ function cleanup() {
function realtime_cleanup() {
mkdir -p ../realtime_delete/data
DATE_TO_CLEANUP=`date +"%Y%m%d" -d "-7 days"`
- cat ../data/*${DATE_TO_CLEANUP}*.succ | $PYTHON_BIN delete_succ.py 2> ../log/realtime_cleanup.log
+ cat ../data/*${DATE_TO_CLEANUP}*.succ | $PYTHON_BIN delete.py --format json 2> ../log/realtime_cleanup.log
rm -f ../data/*${DATE_TO_CLEANUP}*
}
commit 47a2565e033dc1ed60a0ffd4df5e760dbcaebad8
Author: lishuailong <lishuailong@baidu.com>
Date: Thu Jul 6 16:18:47 2017 +0800
fix realtime cleanup
diff --git a/bin/server_control b/bin/server_control
index 13b756f..6d81daa 100755
--- a/bin/server_control
+++ b/bin/server_control
@@ -48,7 +48,7 @@ function cleanup() {
function realtime_cleanup() {
mkdir -p ../realtime_delete/data
DATE_TO_CLEANUP=`date +"%Y%m%d" -d "-7 days"`
- cat ../data/*${DATE_TO_CLEANUP}.succ | $PYTHON_BIN delete_succ.py 2> ../log/realtime_cleanup.log
+ cat ../data/*${DATE_TO_CLEANUP}*.succ | $PYTHON_BIN delete_succ.py 2> ../log/realtime_cleanup.log
rm -f ../data/*${DATE_TO_CLEANUP}*
}
exists as long as the feature is in development
When the development of a feature takes a long time, it may be useful to continuously merge from develop into the feature branch. This has the following advantages:
develop in the feature branch.develop that will happen at a later point.Jedi Mind Tricks for Git
@jankrag & @randomsort (slides, demo-repo)
diffalso: @_flexbox's sketch notes
Git Simple: Writing primary git functionalities in Ruby
Repo 911
repo, BFG & LFS; also @_flexbox's sketch notes
Git and the Terrible, Horrible, No Good, Very Bad Day
git clone https://github.com/hectorsector/git-and-the-bad-day.gitgit lol = alias git log --oneline plus which other options?git diff with .. vs ...? one is against merge basealso: @_flexbox's sketch notes
The Battle for Sub-premacy
with @kylemacey, see @_flexbox's sketch notes
Greatest Hits of the Git Maintainers Room: 2016
also: @_flexbox's sketch notes
Nice intro of git submodule
When .git/HEAD is gone, git doesn't even think your repository is a repository. So really, we must fix this first or else we will not be able to use any git commands to salvage the rest.
After a recent power outage, a call to 'git status' returned this:
fatal: Not a git repository (or any of the parent directories): .git
When I inspected .git/HEAD, it was filled with what looked like binary code, rather than a string like:
ref: refs/heads/master
or
ref: refs/heads/develop
This:
echo 'ref: refs/heads/develop' > ./git/HEAD
did the trick!
Git for teachers
I use etckeeper on my Arch Linux boxen, to great joy
The best way to find branches I've recently used is to use the following command: git for-each-ref --sort=-committerdate refs/heads/
git for-each-ref --sort='-committerdate' --format='%(refname)%09%(committerdate)' refs/heads | sed -e 's-refs/heads/--'
If you want a deeper explanation skip down to "The long version". ref~ is shorthand for ref~1 and means the commit's first parent. ref~2 means the commit's first parent's first parent. ref~3 means the commit's first parent's first parent's first parent. And so on. ref^ is shorthand for ref^1 and means the commit's first parent. But where the two differ is that ref^2 means the commit's second parent (remember, commits can have two parents when they are a merge). The ^ and ~ operators can be combined.
Issues can be reported at: https://github.com/hypothesis/h/issues
Git Basics So, what is Git in a nutshell?
Getting started with Git
Rule of thumb: When pulling changes from origin/develop onto your local develop use rebase. When finishing a feature branch merge the changes back to develop.
If Master has diverged since the feature branch was created, then merging the fea - ture branch into master will create a merge commit. This is a typical merge.
Git is revolutionary because it gives you the best of both worlds. You can regularly check in changes while prototyping a solution but deliver a clean history when you’re finished. When this is your goal, Git’s defaults make a lot more sense.
Git gets this basic division of worlds right and is a fundamental departure from other version control systems like SVN. The feature that enables all this is nearly cost-free, instantaneous branching.
What makes this new world complex is not due to git, but instead because the world is, quite simply, complex! Good tools like git help us manage (some of) the complexity.
If you’re fighting Git’s defaults, ask why. Treat public history as immutable, atomic, and easy to follow. Treat private history as disposable and malleable. The intended workflow is: Create a private branch off a public branch. Regularly commit your work to this private branch. Once your code is perfect, clean up its history. Merge the cleaned-up branch back into the public branch.
Good defaults are sometimes hard to recognize, especially when the tool is complex.
Questioning the defaults-- and deciding why you would keep them or change them-- is a good antidote to dismissing something due to not understanding it.
If you can't understand why you don't like the defaults, then decide what you would choose instead and why you would change the default as it stands. Does the default make it easy to do the "right" thing AND hard to do the "wrong" thing? The second part of that statement is the most important since it might not be obvious what the "right" thing is.
Even if you don't like the defaults, ask yourself if they continually lead you away from perils and problems that would plague you if a different set of defaults were chosen?