Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git is my buddy: Effective Git as a solo developer

mikkel.ca

Post reply on HN
Print view View original

141–150 of 212 posts

Re: Git is my buddy: Effective Git as a solo developer

#141

Post by dpedu »

colllectorof wrote: post #105
gregmac wrote: post #96

Earlier quoted context omitted.

> it makes me feel safer This for me is one of the biggest things I like about working under version control, even solo. It gives me the freedom to explore some crazy idea or refactor without having to think about the way back if it doesn't pan out. If it turns out to be more complex than I am willing to do now, I can stash or branch. If I think back to my pre-source control days, I used to leave commented code every…

Modern IDEs often ave basic source control baked in. You don't even need to commit anything. I wonder whether there is any point in using Git for basic version control if those features are already available.

Committing aside, git also has stash. Many people prefer using one consistent tool (git) over the variety of IDE's equivalent features available.

Re: Git is my buddy: Effective Git as a solo developer

#142

Post by PeterWhittaker »

moosebear847 wrote: post #21

Anyone know a clean way to have nested git projects? Every time I make a commit in B (the nested git project), there are changes in A. Previous searching of a solution was hard to understand..

I’ve some ideas based on recent work, but I want to make sure I understand your use case: should changes to A and B be independent, but A and B require each other to do useful work?

Re: Git is my buddy: Effective Git as a solo developer

#143

Post by paledot »

nine_k wrote: post #51
phailhaus wrote: post #47

As others have mentioned, trying to keep your commits atomic while simultaneously working on several features at once is basically impossible since they're immutable. And given that modern source-control platforms (e.g., GitHub) support squashing on merge, it's pretty much unnecessary. You get "atomic commits", "every commit has tests", even "clean git history" just by squashing your PR's on merge, so PR's become ato…

Small incremental commits on a feature branch, which allow for fine-grained development and review. Large squashed commits on the main branch, each representing an approved and merged PR, which allow for a reasonable history of features and fixes.

Nothing says "readable history" like 1000 lines in a single commit.

Re: Git is my buddy: Effective Git as a solo developer

#144

Post by offtop5 »

tpmx wrote: post #130
offtop5 wrote: post #127

Earlier quoted context omitted.

git init git add . git commit . -m uh git push Doesn't look too hard to me. Particularly when I'm going to rewrite my system, I'll go ahead and check out a new Branch so I don't freak out when I break everything. Infact I tell a developer to learn git first. The only time git becomes an issue is when you have large binary objects, like with a video game. Git LFS is pain.

I figure it takes 3-4 weeks for a typical newbie developer to learn git in depth. That's too much compared to the benefits. Git is way too complex and the CLI is badly designed, especially for a solo developer. The crux with git is that you really do have to learn it in depth, if you want to be self-sufficent in the end.

You can use GitHub when you're getting started.

I found get to be an extremely useful tool when I needed to go back and look over some of the changes I made.

Re: Git is my buddy: Effective Git as a solo developer

#145

Post by PeterWhittaker »

Whether a branch should do one thing or a collection of things, for me, depends on how big/complex is the thing.

If I’m making a very small change, e.g., a fix, I’ll work on master directly (personal work only! Shared work always uses the way we’ve agreed to work!).

A slightly more complex change or an exploration or experimental change will get its own branch.

A very complex change will have a base branch and feature branches off that base, possibly with issues, one per feature, merged into the base branch, which will eventually be rebased on then merged into master.

Re: Git is my buddy: Effective Git as a solo developer

#146

Post by lamontcg »

gmfawcett wrote: post #27
rrosen326 wrote: post #2

I'm also a solo developer and use git in a much less sophisticated fashion. I tend to use it as, "freeze my code here, so in case I f something up, I can get back to a moderately clean state." It's kind like a snapshot-based local history. And, quite frankly, I rarely revert one, but it makes me feel safer. I don't care if I have a lot of commit messages that say, "interim". The good ones are clear. Is this a terribl…

Quite a few people are suggesting that, when it's time to share your code with others, maybe you should squash/rebase it to clean things up. That's totally up to you... but just know that not everyone thinks rebasing is a good idea. See [1], for example. [1] https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md I think we often feel the urge to rebase and squash not because it actually makes our code changes easier…

My commit history is often a descent into profane madness.

Re: Git is my buddy: Effective Git as a solo developer

#147

Post by tpmx »

offtop5 wrote: post #144
tpmx wrote: post #130

Earlier quoted context omitted.

I figure it takes 3-4 weeks for a typical newbie developer to learn git in depth. That's too much compared to the benefits. Git is way too complex and the CLI is badly designed, especially for a solo developer. The crux with git is that you really do have to learn it in depth, if you want to be self-sufficent in the end.

You can use GitHub when you're getting started. I found get to be an extremely useful tool when I needed to go back and look over some of the changes I made.

No, that doesn't help much in understanding git to the level that you're self-sufficent.

Re: Git is my buddy: Effective Git as a solo developer

#148

Post by jpitz »

Wowfunhappy wrote: post #116
nemetroid wrote: post #37

Earlier quoted context omitted.

> Who do we really help by pretending that we're more organized, coherent, and linear than we actually were? We're helping the future reader who's reading the history because they want to understand why a change was made - and "because the author of the branch initially had the wrong idea" is almost never the answer they're looking for. I sometimes enjoy reading stream-of-consciousness writing, but most of the time (…

As a much newer developer, the biggest problem I have with git is that I rarely end up actually making one change at a time. I'll be working on some larger thing, and in the process I'll notice and quickly fix a smaller thing before returning to the original task. This might be a typo in a code comment, a poorly named variable, or a block of code I realize is dead. I suspect this is the type of tendency which goes aw…

With the add command's interactive mode, it is often possible to selectively stage and commit individual patches in a file.

https://git-scm.com/book/en/v2/Git-Tools-Interactive-Staging

Re: Git is my buddy: Effective Git as a solo developer

#149

Post by bentcorner »

Wowfunhappy wrote: post #116
nemetroid wrote: post #37

Earlier quoted context omitted.

> Who do we really help by pretending that we're more organized, coherent, and linear than we actually were? We're helping the future reader who's reading the history because they want to understand why a change was made - and "because the author of the branch initially had the wrong idea" is almost never the answer they're looking for. I sometimes enjoy reading stream-of-consciousness writing, but most of the time (…

As a much newer developer, the biggest problem I have with git is that I rarely end up actually making one change at a time. I'll be working on some larger thing, and in the process I'll notice and quickly fix a smaller thing before returning to the original task. This might be a typo in a code comment, a poorly named variable, or a block of code I realize is dead. I suspect this is the type of tendency which goes aw…

Look at `git add -i`. You can commit just part of a change to a file. So if you notice a small problem and already have a bunch of changes made, you can still make those changes, and commit them separately.

Up to you if you wanted to rebase those changes back onto main.

I don't use it often and find it's kind of painful to use, but if you're in the position where you've already saved two different things in your IDE and need to pull them apart for commit, it's a useful tool.

Re: Git is my buddy: Effective Git as a solo developer

#150

Post by systemvoltage »

hinkley wrote: post #135
gregmac wrote: post #96

Earlier quoted context omitted.

> it makes me feel safer This for me is one of the biggest things I like about working under version control, even solo. It gives me the freedom to explore some crazy idea or refactor without having to think about the way back if it doesn't pan out. If it turns out to be more complex than I am willing to do now, I can stash or branch. If I think back to my pre-source control days, I used to leave commented code every…

Exploratory refactoring turns out to be very close to an exercise in creative writing, as I learned one day accidentally from my lit major friend. Take the section you are stuck on, print it out, cut it up into sentences or phrases, and just rearrange them until either it makes sense, or you figure out where you went wrong. Rearranging code statements until something makes sense is exactly what refactoring is.

I beg to differ.

Refactoring is not merely rearranging code statements. Refactoring is restructuring of the code starting from the architectural and abstract goal and then looking at how pieces of existing code would fit. Sometimes, that requires writing new code and tests. Refactoring by definition also means not breaking the user space.

I've never heard of any serious writer printing out their prose and cutting it and rearranging it. That just sounds absurdly unnecessary to me.

Post reply on HN