DEV Community

loading...

Discussion on: Avoid messy git history, use linear history

Collapse
bladesensei profile image
coyla Author

Hi ! PAxel

  • You know where the problem has started because before merging and break the master for example, has receive a pull request. So they know WHO, the Branch that has caused the problem.

I used gitkraken for a while, i realized that i don't need it anymore. But the main problem is the maintenance not only the visual. Visual is a secondary problem, developer we should always try to work properly for ourself and team members, for future work even if there is something that we don't see everyday like a git history, a documentations ...

Collapse
paxel profile image
paxel

hey coyla,
we don't use github or gitlab pull requests. just plain git. if you fast forward a merge, you don't see any branches or info without diving into the internals. in our company we try to pull with ff and only rebase if it fails to avoid a) pull merges and b) accidental rebases of merged branches. we also merge no ff always to keep the branch name information. for multiple reasons.

sometimes it goes wrong and everything looks shit. most of the time we have clean feature branches.

I guess in the end it's always what the team decides for and if everyone is happy every solution can be the best one.

Thread Thread
bladesensei profile image
coyla Author

Yes. It depends of the team. I remember that some people said in our last team " we need to keep track of the release branch" so must of the time we used rebase and sometimes normal merge (for releases) as you say.. thanks to share your way to do 🙇✌️✌️