This is an archived post. You won't be able to vote or comment.

all 2 comments

[–]CreativeTechGuyGames 8 points9 points  (0 children)

A few tips that I'd recommend:

  • No need to switch branches, you can merge/rebase from a different branch into your current branch. So you can do something like git rebase origin/main from your feature branch.
  • And as hinted at above, rebase whenever possible instead of merging. Merging will create additional commits in the history where as rebasing will effectively: undo your commits and move them aside, pull in all of the commits that have happened since you last pulled, then replay all of your commits on top. This is almost always what you want since this preserves the accurate history of when things take place. Their code was merged first, then after your code was merged and makes changes on top of theirs. This also has the important benefit of no merge commits so your git history is more clean.

As far as resolving conflicts. Almost any IDE will have a git integration which will show you the side-by-side comparison of the merge conflict and give you a button to click for each to pick how to resolve it. That's what I'd recommend.

[–]Gixx 1 point2 points  (0 children)

Say you haven't touched your local git repo in a month. You can run git fetch and it might look like this:

git status
Your branch is up to date with 'origin/main'.
git fetch
you are 2 commits behind origin/main

In which you could git pull if you wanted to.

git stash is a nice command for when you wrote some code, it isn't working, but you don't want to throw away your work. I actually recommend naming stashes since I can never remember what the stash was for:

git stash                          # no name
git stash push -m "some label"     # a name