136 Matching Annotations
  1. Jul 2020
    1. "that text has been removed from the official version on the Apache site." This itself is also not good. If you post "official" records but then quietly edit them over time, I have no choice but to assume bad faith in all the records I'm shown by you. Why should I believe anything Apache board members claim was "minuted" but which in fact it turns out they might have just edited into their records days, weeks or years later? One of the things I particularly watch for in modern news media (where no physical artefact captures whatever "mistakes" are published as once happened with newspapers) is whether when they inevitably correct a mistake they _acknowledge_ that or they instead just silently change things.
    2. If the reality is you pushed out a release that doesn't even compile, and then you spotted the typo six minutes later, that's fine, that's what the git repo should show. Don't come to me asking if there's a way to change history so that it seems as if it didn't happen that way. How does that help anybody?

      To answer your question:

      How does that help anybody?

      It keeps the history clean.

      Assuming they push up an amended commit minutes after the bad commit, this shouldn't cause too much of a problem. (Depends how many people are working on it and how often they git pull.)

      How does it help anyone to keep 2 separate commits that, semantically, could and should have been just 1? How does it help anyone to have a permanent record of someone's mistake?

      If it can be easily and quickly fixed, I say go for it!

    1. If we do not care about untracked files in the working directory, we can use the --untracked-files=no option to disregard those:
    1. This commit does not belong to any branch on this repository.

      How would I download this commit/changeset with a git client then?? Or is it simply the case that if someone ever deletes the source branch for a merge request and "orphans" those commits, that there is now no longer a way to download it via the usual git fetch methods and the only way now to view these commits is via the web interface?

      Idea: Create a permanent tag for every version of every pull request that gets pushed up. (Which maybe the already do internally to prevent it from being GC'd?)

      https://github.com/ruby/ruby/pull/1758

      Ana06 deleted the Ana06:array-diff branch on Apr 30, 2019

  2. Jun 2020
    1. uses a pre-clone step to seed the project with a recent archive of the repository. This is done for several reasons: It speeds up builds because a 800 MB download only takes seconds, as opposed to a full Git clone.
  3. May 2020
    1. After the initial backup, future backups are differential, both in the files that are transferred and the files that are stored on your behalf.

      I guess git can help with the differential part of the backup, but how exactly does it? In order for it to help with transfer from the subject server, wouldn't it have to keep the git repo on that server? Otherwise wouldn't it have to transfer everything to the remote cloud git repo so that git can do the diff there?

      Makes me wonder if simple rsync wouldn't be more efficient than all this.

    2. the files are then transferred over the to git repository onto the cloud server.
    1. git describe [--tags] describes the current branch in terms of the commits since the most recent [possibly lightweight] tag in this branch's history. Thus, the tag referenced by git describe may NOT reflect the most recently created tag overall.
    1. What I think we're lacking is proper tooling, or at least the knowledge of it. I don't know what most people use to write Git commits, but concepts like interactive staging, rebasing, squashing, and fixup commits are very daunting with Git on the CLI, unless you know really well what you're doing. We should do a better job at learning people how to use tools like Git Tower (to give just one example) to rewrite Git history, and to produce nice Git commits.
  4. Apr 2020
    1. Notebook files, however, are essentially giant JSON documents that contain the base-64 encoding of images and binary data. For a complex notebook, it would be extremely hard for anyone to read through a plaintext diff and draw meaningful conclusions—a lot of it would just be rearranged JSON and unintelligible blocks of base-64.

      Git traces plaintext differences and with notebooks it's a problem

    2. There is no hidden state or arbitrary execution order in a YAML file, and any changes you make to it can easily be tracked by Git

      In comparison to notebooks, YAML is more compatible for Git and in the end might be a better solution for ML

    1. git commit --amend --author="John Doe <john@doe.org>"

      Update the author for a git commit

    1. gh repo create hello-world -d "A react app for the web" --public

      GitHub released a new CLI: gh with which you can do much more operations.

      For example, you can create repo without going into your browser:

      gh repo create hello-world -d "A react app for the web" --public
      

      Generally, it will be great for CI/CD pipelines

    1. git reflog is a very useful command in order to show a log of all the actions that have been taken! This includes merges, resets, reverts: basically any alteration to your branch.

      Reflog - shows the history of actions in the repo.

      With this information, you can easily undo changes that have been made to a repository with git reset

      git reflog
      

      reflog animation

      Say that we actually didn't want to merge the origin branch. When we execute the git reflog command, we see that the state of the repo before the merge is at HEAD@{1}. Let's perform a git reset to point HEAD back to where it was on HEAD@{1}!

      reflog + reset animation

    2. it pull is actually two commands in one: a git fetch, and a git merge. When we're pulling changes from the origin, we're first fetching all the data like we did with a git fetch, after which the latest changes are automatically merged into the local branch.

      Pulling - downloads content from a remote branch/repository like git fetch would do, and automatically merges the new changes

      git pull origin master
      

      pulling animation

    3. It doesn't affect your local branch in any way: a fetch simply downloads new data.

      Fetching - downloads content from a remote branch or repository without modifying the local state

      git fetch origin master
      

      fetching animation

    4. When a certain branch contains a commit that introduced changes we need on our active branch, we can cherry-pick that command! By cherry-picking a commit, we create a new commit on our active branch that contains the changes that were introduced by the cherry-picked commit.

      Cherry-picking - creates a new commit with the changes that the cherry-picked commit introduced.

      By default, Git will only apply the changes if the current branch does not have these changes in order to prevent an empty commit

      git cherry-pick 76d12
      

      cherry-picking animation

    5. Another way of undoing changes is by performing a git revert. By reverting a certain commit, we create a new commit that contains the reverted changes!

      Reverting - reverts the changes that commits introduce. Creates a new commit with the reverted changes

      git revert ec5be
      

      reverting animation

    6. Sometimes, we don't want to keep the changes that were introduced by certain commits. Unlike a soft reset, we shouldn't need to have access to them any more.

      Hard reset - points HEAD to the specified commit.

      Discards changes that have been made since the new commit that HEAD points to, and deletes changes in working directory

      git reset --hard HEAD~2
      git status
      

      hard reset animation

    7. git rebase copies the commits from the current branch, and puts these copied commits on top of the specified branch.

      Rebasing - copies commits on top of another branch without creating a commit, which keeps a linear history.

      Changes the history as new hashes are created for the copied commits.

      git rebase master
      

      A big difference compared to merging, is that Git won't try to find out which files to keep and not keep. The branch that we're rebasing always has the latest changes that we want to keep! You won't run into any merging conflicts this way, and keep a nice linear Git history.

      Rebasing is great whenever you're working on a feature branch, and the master branch has been updated.

      rebasing animation

    8. This can happen when the two branches we're trying to merge have changes on the same line in the same file, or if one branch deleted a file that another branch modified, and so on.

      Merge conflict - you have to decide from which branch to keep the change.

      After:

      git merge dev
      

      Git will notify you about the merge conflict so you can manually remove the changes you don't want to keep, save them, and then:

      git add updated_file.md
      git commit -m "Merge..."
      

      merge conflict animation

    9. If we committed changes on the current branch that the branch we want to merge doesn't have, git will perform a no-fast-forward merge.

      No-fast-forward merge - default behavior when current branch contains commits that the merging branch doesn't have.

      Create a new commit which merges two branches together without modifying existing branches.

      git merge dev
      

      no-fast-forward merge animation

    10. fast-forward merge can happen when the current branch has no extra commits compared to the branch we’re merging.

      Fast-forward merge - default behavior when the branch has all of the current branch's commits.

      Doesn't create a new commit, thus doesn't modify existing branches.

      git merge dev
      

      fast-forward merge animation

    11. soft reset moves HEAD to the specified commit (or the index of the commit compared to HEAD), without getting rid of the changes that were introduced on the commits afterward!

      Soft reset - points HEAD to the specified commit.

      Keeps changes that have been made since the new commit the HEAD points to, and keeps the modifications in the working directory

      git reset --soft HEAD~2
      git status
      

      soft reset animation

    12. git reset gets rid of all the current staged files and gives us control over where HEAD should point to.

      Reset - way to get rid of unwanted commits. We have soft and hard reset

    13. There are 6 actions we can perform on the commits we're rebasing

      Interactive rebase - makes it possible to edit commits before rebasing.

      Creates new commits for the edited commits which history has been changed.

      6 actions (options) of interactive rebase:

      • reword: Change the commit message
      • edit: Amend this commit
      • squash: Meld commit into the previous commit
      • fixup: Meld commit into the previous commit, without keeping the commit's log message
      • exec: Run a command on each commit we want to rebase
      • drop: Remove the commit
      git rebase -i HEAD~3
      

      drop animation

      squash animation

  5. Mar 2020
    1. git config --global alias.s status

      Replace git status with git s:

      git config --global alias.s status
      

      It will modify config in .gitconfig file.

      Other set of useful aliases:

      [alias]
        s = status
        d = diff
        co = checkout
        br = branch
        last = log -1 HEAD
        cane = commit --amend --no-edit
        lo = log --oneline -n 10
        pr = pull --rebase
      

      You can apply them (^) with:

      git config --global alias.s status
      git config --global alias.d diff
      git config --global alias.co checkout
      git config --global alias.br branch
      git config --global alias.last "log -1 HEAD"
      git config --global alias.cane "commit --amend --no-edit"
      git config --global alias.pr "pull --rebase"
      git config --global alias.lo "log --oneline -n 10"
      
    2. alias g=git
      alias g=git
      

      This command will let you type g s in your shell to check git status

    1. The best commit messages I’ve seen don’t just explain what they’ve changed: they explain why

      Proper commits:

      • explains the reason for the change
      • is searchable (contains the error message)
      • tells a story (explains investigation process)
      • makes everyone a little smarter
      • builds compassion and trust (adds an extra bit of human context)
    1. If you use practices like pair or mob programming, don't forget to add your coworkers names in your commit messages

      It's good to give a shout-out to developers who collaborated on the commit. For example:

      $ git commit -m "Refactor usability tests.
      >
      >
      Co-authored-by: name <name@example.com>
      Co-authored-by: another-name <another-name@example.com>"
      
    2. I'm fond of gitmoji commit convention. It lies on categorizing commits using emojies. I'm a visual person so it fits well to me but I understand this convention is not made for everyone.

      You can add gitmojis (emojis) in your commits, such as:

      :recycle: Make core independent from the git client (#171)
      :whale: Upgrade Docker image version (#167)
      

      which will transfer on GitHub/GitLab to:

      ♻️ Make core independent from the git client (#171)
      🐳 Upgrade Docker image version (#167)
      
    3. Separate subject from body with a blank line Limit the subject line to 50 characters Capitalize the subject line Do not end the subject line with a period Use the imperative mood in the subject line Wrap the body at 72 characters Use the body to explain what and why vs. how

      7 rules of good commit messages.

      >more info<

    1. Don’t commit directly to the master or development branches. Don’t hold up work by not committing local branch changes to remote branches. Never commit application secrets in public repositories. Don’t commit large files in the repository. This will increase the size of the repository. Use Git LFS for large files.  Learn more about what Git LFS is and how to utilize it in this advanced Learning Git with GitKraken tutorial. Don’t create one pull request addressing multiple issues. Don’t work on multiple issues in the same branch. If a feature is dropped, it will be difficult to revert changes. Don’t reset a branch without committing/stashing your changes. If you do so, your changes will be lost. Don’t do a force push until you’re extremely comfortable performing this action. Don’t modify or delete public history. 

      Git Don'ts

    2. Create a Git repository for every new project. Learn more about what a Git repo is in this beginner Learning Git with GitKraken tutorial. Always create a new branch for every new feature and bug. Regularly commit and push changes to the remote branch to avoid loss of work. Include a gitignore file in your project to avoid unwanted files being committed. Always commit changes with a concise and useful commit message.  Utilize git-submodule for large projects. Keep your branch up to date with development branches. Follow a workflow like Gitflow. There are many workflows available, so choose the one that best suits your needs. Always create a pull request for merging changes from one branch to another. Learn more about what a pull request is and how to create them in this intermediate Learning Git with GitKraken tutorial. Always create one pull request addressing one issue. Always review your code once by yourself before creating a pull request. Have more than one person review a pull request. It’s not necessary, but is a best practice. Enforce standards by using pull request templates and adding continuous integrations. Learn more about enhancing the pull request process with templates.  Merge changes from the release branch to master after each release. Tag the master sources after every release. Delete branches if a feature or bug fix is merged to its intended branches and the branch is no longer required. Automate general workflow checks using Git hooks. Learn more about how to trigger Git hooks in this intermediate Learning Git with GitKraken tutorial. Include read/write permission access control to repositories to prevent unauthorized access. Add protection for special branches like master and development to safeguard against accidental deletion.

      Git Dos

    1. To add the .gitattributes to the repo first you need to create a file called .gitattributes into the root folder for the repo.

      With such a content of .gitattributes:

      *.js    eol=lf
      *.jsx   eol=lf
      *.json  eol=lf
      

      the end of line will be the same for everyone

    2. On the Windows machine the default for the line ending is a Carriage Return Line Feed (CRLF), whereas on Linux/MacOS it's a Line Feed (LF).

      Thar is why you might want to use .gitattributes to prevent such differences.

      On Windows Machine if endOfLine property is set to lf

      {
        "endOfLine": "lf"
      }
      

      On the Windows machine the developer will encounter linting issues from prettier:

    3. The above commands will now update the files for the repo using the newly defined line ending as specified in the .gitattributes.

      Use these lines to update the current repo files:

      git rm --cached -r .
      git reset --hard
      
  6. Feb 2020
  7. Jan 2020
    1. This command creates a new blob with the new content. And it updates the index entry for data/number.txt to point at the new blob.
    2. They make the correction and add the file to the index again
    1. git -c core.sshCommand="ssh -vvv" pull

      This seems like the most reliable and direct way to enable debugging of the ssh connection (authentication, etc.) used by a git command.

  8. Dec 2019
    1. Rubydoc.info can automatically fetch and rebuild your docs from your github project everytime you commit! To add a post-receive (commit) hook to Github, simply select the official Rubydoc.info service hook from the list of service hooks in your project settings.
  9. Nov 2019
    1. But in general the guideline is: code should be clean, history should be realistic.
    2. many organizations end up with messy workflows, or overly complex ones.
    3. If you push to a public branch you shouldn't rebase it since that makes it hard to follow what you're improving, what the test results were, and it breaks cherrypicking
  10. Sep 2019
  11. Aug 2019
    1. prepare: Run both BEFORE the package is packed and published, on local npm install without any arguments, and when installing git dependencies
    1. With now more than 3000 modules, there are huge gaps in the quality of things you find in the npm registry. But more often than not, it's easy to find a module that is really close to what you need, except if it wasn't for that one bug or missing feature.
  12. Jun 2019
  13. Mar 2019
    1. 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

  14. Dec 2018
    1. 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"
  15. Nov 2018
  16. Oct 2018
  17. Aug 2018
    1. When you can assume that all the materials you’re using in and with your class are open educational resources, here’s one way to remix the effective practices listed above with OER in order to provide you and your students with opportunities to spend your time and effort on work that makes the world a better place instead of wasting it on disposable assignments.

      As I think of remix, reuse, redistribute and things like git and version control, I also can't help but think that being able to send and receive webmentions in the process of reusing and redistribution with referential links back to the originals will allow the original creator to at least be aware of the changes and their existence to potentially manually add them to the original project. (Manually because they may not (yet) know how to keep their content under source control or allow others to do so and send pull requests.)

    2. Free to accessFree to reuseFree to reviseFree to remixFree to redistributeThe question becomes, then, what is the relationship between these additional capabilities and what we know about effective teaching and learning? How can we extend, revise, and remix our pedagogy based on these additional capabilities?

      I look at this and think immediatly about the Git model of allowing people to not only fork and reuse/redistribute pieces, but what about the ability to do pull requests to take improvements and push them back up the the source so that everyone potentially benefits?

  18. Jun 2018
    1. 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

  19. Apr 2018
    1. 如何将开发的分支代码,merge到主干上?

      • 创建新分支开发

      $ git checkout -b dev

      • 在新分支下新增测试文件

      $ echo 'Readme' > ./readme.txt

      $ git add readme.text

      • 将文件提交到分支

      $ git commit -m "dev branch test"

      • 分支开发工作完成,我们现在可以切回 master 分支

      $ git checkout master

      • 将 dev 分支的工作成果合并到 master 分支上

      $ git merge dev

      • 合并完成之后,dev 分支没有作用就可以放心删除了

      $ git branch -d dev

      • 删除后,查看剩余分支列表,就只剩下 master 分支了

      $ git branch

    2. git checkout -b dev

      创建新的开发分支进行开发,与下面一组命令相同

      $ git branch dev $ git checkout dev

    3. $ git branch dev $ git checkout dev Switched to branch 'dev'

      $$git checkout$$

      命令加上 \(-b\) 参数表示创建并切换

      该命令与 \(git checkout -b dev\) 相同

  20. Feb 2018
    1. log --patch

      same as git show

    2. 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 ..."
    1. 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.

    2. 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.

    3. 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.

  21. Jan 2018
    1. 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.

  22. Dec 2017
  23. Nov 2017
    1. $ 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}*
       }
      
    1. 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:

      • We can use the new features introduced in develop in the feature branch.
      • We simplify the integration merge of the feature branch into develop that will happen at a later point.
  24. Feb 2017
    1. Jedi Mind Tricks for Git

      @jankrag & @randomsort (slides, demo-repo)

      Principles which are supported by hooks presented here
      • never commit on master
      • always reference an issue in commit message (via GitHub API)
      • #serverless, #noOps & delivery through ready-branches
      • hook manager: overcommit (via)
      attributes + drivers to improve diff
      • hexdump binaries
      • convert .docx to .md
      • line-wrap paragraphs
      • metadata of images or audio
      • ASCI-ize image
      • xls2csv, unzip
      filter drivers (process BLObs on save or checkout)
      • enforce lint-/formatting
      • Caesar's obfuscation

      also: @_flexbox's sketch notes

    2. Git Simple: Writing primary git functionalities in Ruby
    3. Repo 911
    4. Git and the Terrible, Horrible, No Good, Very Bad Day

      also: @_flexbox's sketch notes

    5. The Battle for Sub-premacy
    6. Greatest Hits of the Git Maintainers Room: 2016
      renamed to: Greatest Hits from the Ask-Git-Core

      also: @_flexbox's sketch notes

  25. Sep 2016
  26. Apr 2016
    1. 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!

  27. Aug 2015
  28. Jun 2015
    1. The best way to find branches I've recently used is to use the following command: git for-each-ref --sort=-committerdate refs/heads/
  29. May 2015
    1. git for-each-ref --sort='-committerdate' --format='%(refname)%09%(committerdate)' refs/heads | sed -e 's-refs/heads/--'
    1. 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.
  30. Jan 2015
  31. Nov 2014
  32. Jan 2014
    1. 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.
    1. 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.
    1. 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.

    2. 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?