5 ms·

An introduction such as this, should also explain about ways of working with git and not just explain the commands. I still remember the first time when I start

An introduction such as this, should also explain about ways of working with git and not just explain the commands. I still remember the first time when I started working with git, that I was warned never to use rebase, because it could be dangerous. It was only when I moved to another working environment, that I learned how to use it, and only about five months ago that you can add --rebase with the default pull button. But still I find myself using Git Bash shell often. It took me also a long time to learn that origin was the default remote and that you can add more remotes and that you can also push to a repository on a USB drive. I have been working with git for about four years now and it is only in the past year that I feel a little comfortable with it. But still when I look up a git command, I am overwhelmed with the shear number of options. On the other hand, I am still surprised by the number of commands I have to type to do something as simple as rebasing my uncommitted changes with the latest commit from origin. Or what you have to do to squash your commits on the current branch since your lastest push to master (or develop). Git is like a toolkit with relatively small and intricate tools, that often baffle beginners that only want to perform a limited number of operations according to a certain style of working.

legerdemain 6y ago
Fun fact: you can clone a repo on your local disk... to another location on your local disk. > git clone file://<ABSOLUTE_PATH> [<CHECKOUT_NAME>] And once you have a bunch of local checkouts, you can use them as a sandbox for trying out random distributed git workflows.
- sebmellen 6y ago
  This will save me a lot of time. I'm always hopping between branches on the single repo we use to stay in the free-tier. I couldn't find this in the Git documentation, but it works great!
  - legerdemain 6y ago
    I'm a little confused how re-cloning a local clone helps you compared to cloning the original remote repo. You can certainly have multiple clones of the remote repo in multiple locations on disk. To avoid name collisions, you can just not clone to the same parent directory, or choose an alias: `git clone <URL> <ALIAS>`. However, if cloning your monorepo and switching branches takes a long time, consider `git worktree`. This set of commands allows you to clone a repo once, then keep multiple branches checked out at the same time, in different directories. See this, for example.[1] [1] https://spin.atomicobject.com/2016/06/26/parallelize-development-git-worktrees/ https://spin.atomicobject.com/2016/06/26/parallelize-develop...
    - sebmellen 6y ago
      Thanks, that's even better. I need to work on my Git skills, I'll try this out.
Vinnl 6y ago
I find that learning about the ways of working with Git follows relatively naturally after you spend about 10 minutes learning about how Git is modelled. (I created a visual tutorial about that a number of years ago: https://agripongit.vincenttunru.com/ https://agripongit.vincenttunru.com/)
chiefalchemist 6y ago
> An introduction such as this, should also explain about ways of working with git and not just explain the commands. Amen! Too often, and this isn't exclusive to git edu, there's too focus on features and not enough on benefits. Saying "this is the command and this is the syntax" provides no context. Git is especially context sensitivity. Without seeing real life examples of _why_ and _when_ the how is meaningless and in turn forgettable. I also doing understand why these isn't a solid and reliable UI. Maybe there is and I struggle to find it. How fitting? ;) The point being, git is a series of events (commits and merges), or across dimensions (i.e., other team members). It is, at very least, a three dimensional graph. Stuff that into two dimensions and then into a command line well that qualifies as elitism and jargon. The idea behind the tool is excellent, and necessary. But how it's executed? In 2020? It feels too much like a fax machine.
sirmarksalot 6y ago
I understand there's a whole lot of FUD behind rebase, but I still don't like it. To me, a project's branch structure provides a history of how it all went down, and when I'm trying to hunt down a mysterious change in the code, it's all information I can use to figure out exactly why a certain decision was made, and whether it was made on purpose or by accident. I think rebase and squash go together in terms of what you want to get out of the VCS. If you want a clean history, where every commit represents a complete feature, with the knowledge that you can check any commit out and expect it to work, then squash and rebase are your friends. If like me, you want to understand the history of the code, warts and all, then merge is the way to go. Also, I find I can achieve most of the benefits of a rebase workflow by just defaulting to git log --first-parent.
- globular-toast 6y ago
  I really doubt that it's ever necessary to understand the intricate history of each and every developer working on a codebase to be able to track regressions. You're not Poirot. History is an artifact of development and if it's worth keeping then it's worth maintaining. Rebasing serves to clean up the history ready for archiving (ie. merging to master), giving you a long linear line of commits that is possible to bisect to quickly find the source of regressions.
  - kubanczyk 6y ago
    Yep, architecture decision records (ADRs) for the win. Just next to your README file in the repo. But big projects seldom use rebase. This is because it's quite hard to `git revert` an entire change from two weeks before (change being e.g. 50 related commits).
  - juped 6y ago
    You do want to curate topics with interactive rebase, but you probably shouldn't want to destroy useful information by making everything linear. This is a common and I believe misguided thing people do when they don't know about e.g. gitk (which comes with Git, although your OS packager might split it out). It certainly doesn't aid the bisect command at all. It might hinder it (e.g., a whole series becomes bad because you rebased it off a release tag onto some random point; bisect would pinpoint the merge if you had merged it, but you destroyed useful information so it can only pinpoint one of the diffs). As you say, you definitely don't want to archive every weird developer fumble during development. That's useless noise that makes the history unreadable.

legerdemain 6y ago

Fun fact: you can clone a repo on your local disk... to another location on your local disk. > git clone file://<ABSOLUTE_PATH> [<CHECKOUT_NAME>] And once you have a bunch of local checkouts, you can use them as a sandbox for trying out random distributed git workflows.

sebmellen 6y ago
This will save me a lot of time. I'm always hopping between branches on the single repo we use to stay in the free-tier. I couldn't find this in the Git documentation, but it works great!
- legerdemain 6y ago
  I'm a little confused how re-cloning a local clone helps you compared to cloning the original remote repo. You can certainly have multiple clones of the remote repo in multiple locations on disk. To avoid name collisions, you can just not clone to the same parent directory, or choose an alias: `git clone <URL> <ALIAS>`. However, if cloning your monorepo and switching branches takes a long time, consider `git worktree`. This set of commands allows you to clone a repo once, then keep multiple branches checked out at the same time, in different directories. See this, for example.[1] [1] https://spin.atomicobject.com/2016/06/26/parallelize-development-git-worktrees/ https://spin.atomicobject.com/2016/06/26/parallelize-develop...
  - sebmellen 6y ago
    Thanks, that's even better. I need to work on my Git skills, I'll try this out.

Vinnl 6y ago

I find that learning about the ways of working with Git follows relatively naturally after you spend about 10 minutes learning about how Git is modelled. (I created a visual tutorial about that a number of years ago: https://agripongit.vincenttunru.com/ https://agripongit.vincenttunru.com/)

chiefalchemist 6y ago

> An introduction such as this, should also explain about ways of working with git and not just explain the commands. Amen! Too often, and this isn't exclusive to git edu, there's too focus on features and not enough on benefits. Saying "this is the command and this is the syntax" provides no context. Git is especially context sensitivity. Without seeing real life examples of _why_ and _when_ the how is meaningless and in turn forgettable. I also doing understand why these isn't a solid and reliable UI. Maybe there is and I struggle to find it. How fitting? ;) The point being, git is a series of events (commits and merges), or across dimensions (i.e., other team members). It is, at very least, a three dimensional graph. Stuff that into two dimensions and then into a command line well that qualifies as elitism and jargon. The idea behind the tool is excellent, and necessary. But how it's executed? In 2020? It feels too much like a fax machine.

sirmarksalot 6y ago

I understand there's a whole lot of FUD behind rebase, but I still don't like it. To me, a project's branch structure provides a history of how it all went down, and when I'm trying to hunt down a mysterious change in the code, it's all information I can use to figure out exactly why a certain decision was made, and whether it was made on purpose or by accident. I think rebase and squash go together in terms of what you want to get out of the VCS. If you want a clean history, where every commit represents a complete feature, with the knowledge that you can check any commit out and expect it to work, then squash and rebase are your friends. If like me, you want to understand the history of the code, warts and all, then merge is the way to go. Also, I find I can achieve most of the benefits of a rebase workflow by just defaulting to git log --first-parent.

globular-toast 6y ago
I really doubt that it's ever necessary to understand the intricate history of each and every developer working on a codebase to be able to track regressions. You're not Poirot. History is an artifact of development and if it's worth keeping then it's worth maintaining. Rebasing serves to clean up the history ready for archiving (ie. merging to master), giving you a long linear line of commits that is possible to bisect to quickly find the source of regressions.
- kubanczyk 6y ago
  Yep, architecture decision records (ADRs) for the win. Just next to your README file in the repo. But big projects seldom use rebase. This is because it's quite hard to `git revert` an entire change from two weeks before (change being e.g. 50 related commits).
- juped 6y ago
  You do want to curate topics with interactive rebase, but you probably shouldn't want to destroy useful information by making everything linear. This is a common and I believe misguided thing people do when they don't know about e.g. gitk (which comes with Git, although your OS packager might split it out). It certainly doesn't aid the bisect command at all. It might hinder it (e.g., a whole series becomes bad because you rebased it off a release tag onto some random point; bisect would pinpoint the merge if you had merged it, but you destroyed useful information so it can only pinpoint one of the diffs). As you say, you definitely don't want to archive every weird developer fumble during development. That's useless noise that makes the history unreadable.