3 ms·

Once you get the essence of git (objects, graph, commits as snapshots etc) everything becomes really easy. You don't need to memorize all command just need to u

Once you get the essence of git (objects, graph, commits as snapshots etc) everything becomes really easy. You don't need to memorize all command just need to understand some basic concepts. And some points about the article. Git is a framework actually, you need some workflow to use it in a team. So git requires a lot of discipline from all team members. You can't just "commit" as in subversion, you must understand what are you doing. So you can't directly compare git with something like subversion. And git ≠ github. Some points are valid: bad and unclear documentation, no "included" workflows, bad command line UI. Author also didn't mention authorship issues, it's a real pain.

cglouch 10y ago
One resource I've found pretty useful for understanding git is http://think-like-a-git.net/ http://think-like-a-git.net/ (also linked at the end of the article). It basically describes git in terms of a directed acyclic graph, where branches/tags give you starting points into the underlying DAG, and the various commands allow you to perform manipulations on it. Once I started thinking about it this way, it made a lot more sense. That said, the command line UI really is infuriating - checkout means 3 different things depending on what the argument is, it's never clear to me whether I should be using "origin master" or "origin/master," etc. I'm also not entirely sold on the usefulness of the index, but perhaps that's cause I'm still new to using git.
lisivka 10y ago
git-flow[1] is implementation of a flow with better UX. You can fork it and modify to fit your needs. [1] https://github.com/petervanderdoes/gitflow-avh https://github.com/petervanderdoes/gitflow-avh
jogjayr 10y ago
> You can't just "commit" as in subversion, you must understand what are you doing. Further I'd argue the subversion "just commit" model is potentially toxic to the quality of the codebase and SCM logs. It makes the act of sharing code with others overly casual. Users therefore often don't become proficient in the proper use of SCMs in general. They write poor commit messages, or may not have a clear understanding of changes introduced by their commit (this goes double for IDE-integrated SCM plugins that I've generally found to have poor UI and lack good affordances for grokking what's happening at any point). The stage -> commit -> push (often to feature branch) provides multiple checkpoints to find issues in your code before it makes it into master/trunk. While staging (especially if you're using a GUI) you have a chance to view the changes being staged. After committing and before pushing, if you find something else that you missed, you can quickly amend your commit without much harm done. The pull request mechanism added by Github provides an additional code review step for a final sanity check and also allows you to run tests on branches before allowing merges (contrasted with the common practice of allowing everyone trunk privileges in SVN, often with a post-commit code review). Rebasing is a an act of final resort for cleaning up your work before everyone else is burdened with the job of grokking and maintaining it for the remaining lifetime of the system. EDIT: Some of these practices are possible to replicate in SVN (eg. do an svn diff and really review the changes before committing) but there's no chance of amending commits, private or features branches are less frequently adopted and rebasing is equivalent to FTL travel and immortality from an SVN viewpoint.
dancing_shark 10y ago
One source that really helped me learn advanced git are the extended manual pages here: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/ It describes advanced features like `git-govern-origin` and `git-organize-head` [0]. [0]. https://git-man-page-generator.lokaltog.net/#26463b871524ca4e6cf1ed715abc208e https://git-man-page-generator.lokaltog.net/#26463b871524ca4...
wodenokoto 10y ago
Any recommendations for resources on workflows for GIT? I mostly write ML code as a single author and there's a lot of experimenting going on, so often I sit at the end of the day and write a commit message along the lines of "dicking around" or "updated some files" and feel like I might as well just sync my stuff with Dropbox and not have to worry about all the GIT commands.
- BerislavLopac 10y ago
  This is possible the best overview of a number of tried and tested workflows: https://about.gitlab.com/2014/09/29/gitlab-flow/ https://about.gitlab.com/2014/09/29/gitlab-flow/ They're naturally recommending the GitLab Flow, but a good approach is to read through it and choose what might work for you. The important thing is to keep in mind that there are countless variables that will likely be different for each team -- team size, release schedule, build process, testing etc -- which mean that each team's flow will be somewhat specific. And as for commit messages, I have developed a system which helps me write more meaningful messages with just a little bit of discipline: instead of summarising what I did, I try to figure how would I give instructions to someone to do the same. So I have things like "refactor MyBigFunction to individual methods" or "change SomeSetting to use float instead of int" or "implement NewClass".
stevage 10y ago
Author here. Yeah, the lack of authorship (and any kind of user awareness, really) is a pain. There are so many ways in which Git has simply failed. It was basically an experimental piece of software designed for a hypothetical world which never really eventuated. Truly distributed version control (code shared between different servers) turned out to be a fringe use case, and the vast majority of all collaborative developed source code has a primary repository. So it has all these features built around the edge case, and a lack of features for the primary case (many users, with different levels of trust, contributing to one repo). Gitless is pretty cool. http://gitless.com/ http://gitless.com/

cglouch 10y ago

One resource I've found pretty useful for understanding git is http://think-like-a-git.net/ http://think-like-a-git.net/ (also linked at the end of the article). It basically describes git in terms of a directed acyclic graph, where branches/tags give you starting points into the underlying DAG, and the various commands allow you to perform manipulations on it. Once I started thinking about it this way, it made a lot more sense. That said, the command line UI really is infuriating - checkout means 3 different things depending on what the argument is, it's never clear to me whether I should be using "origin master" or "origin/master," etc. I'm also not entirely sold on the usefulness of the index, but perhaps that's cause I'm still new to using git.

lisivka 10y ago

git-flow[1] is implementation of a flow with better UX. You can fork it and modify to fit your needs. [1] https://github.com/petervanderdoes/gitflow-avh https://github.com/petervanderdoes/gitflow-avh

jogjayr 10y ago

> You can't just "commit" as in subversion, you must understand what are you doing. Further I'd argue the subversion "just commit" model is potentially toxic to the quality of the codebase and SCM logs. It makes the act of sharing code with others overly casual. Users therefore often don't become proficient in the proper use of SCMs in general. They write poor commit messages, or may not have a clear understanding of changes introduced by their commit (this goes double for IDE-integrated SCM plugins that I've generally found to have poor UI and lack good affordances for grokking what's happening at any point). The stage -> commit -> push (often to feature branch) provides multiple checkpoints to find issues in your code before it makes it into master/trunk. While staging (especially if you're using a GUI) you have a chance to view the changes being staged. After committing and before pushing, if you find something else that you missed, you can quickly amend your commit without much harm done. The pull request mechanism added by Github provides an additional code review step for a final sanity check and also allows you to run tests on branches before allowing merges (contrasted with the common practice of allowing everyone trunk privileges in SVN, often with a post-commit code review). Rebasing is a an act of final resort for cleaning up your work before everyone else is burdened with the job of grokking and maintaining it for the remaining lifetime of the system. EDIT: Some of these practices are possible to replicate in SVN (eg. do an svn diff and really review the changes before committing) but there's no chance of amending commits, private or features branches are less frequently adopted and rebasing is equivalent to FTL travel and immortality from an SVN viewpoint.

dancing_shark 10y ago

One source that really helped me learn advanced git are the extended manual pages here: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/ It describes advanced features like `git-govern-origin` and `git-organize-head` [0]. [0]. https://git-man-page-generator.lokaltog.net/#26463b871524ca4e6cf1ed715abc208e https://git-man-page-generator.lokaltog.net/#26463b871524ca4...

wodenokoto 10y ago

Any recommendations for resources on workflows for GIT? I mostly write ML code as a single author and there's a lot of experimenting going on, so often I sit at the end of the day and write a commit message along the lines of "dicking around" or "updated some files" and feel like I might as well just sync my stuff with Dropbox and not have to worry about all the GIT commands.

BerislavLopac 10y ago
This is possible the best overview of a number of tried and tested workflows: https://about.gitlab.com/2014/09/29/gitlab-flow/ https://about.gitlab.com/2014/09/29/gitlab-flow/ They're naturally recommending the GitLab Flow, but a good approach is to read through it and choose what might work for you. The important thing is to keep in mind that there are countless variables that will likely be different for each team -- team size, release schedule, build process, testing etc -- which mean that each team's flow will be somewhat specific. And as for commit messages, I have developed a system which helps me write more meaningful messages with just a little bit of discipline: instead of summarising what I did, I try to figure how would I give instructions to someone to do the same. So I have things like "refactor MyBigFunction to individual methods" or "change SomeSetting to use float instead of int" or "implement NewClass".

stevage 10y ago

Author here. Yeah, the lack of authorship (and any kind of user awareness, really) is a pain. There are so many ways in which Git has simply failed. It was basically an experimental piece of software designed for a hypothetical world which never really eventuated. Truly distributed version control (code shared between different servers) turned out to be a fringe use case, and the vast majority of all collaborative developed source code has a primary repository. So it has all these features built around the edge case, and a lack of features for the primary case (many users, with different levels of trust, contributing to one repo). Gitless is pretty cool. http://gitless.com/ http://gitless.com/